►
From YouTube: Merge Implementers' Call 1
Description
A
This
goal
is
supposed
to
be
the
technical
discussion
around
the
merge
yep
thanks
for
the
agenda,
danny
yeah
and
all
the
most
of
the
governance
discussion
is
dedicated
to
the
all
core
devs
call,
so
this
is
just
focus
on
technical
stuff.
Today
we
have
like
a
huge
chunk
of
discussion
around
the
application
layer.
A
I
think
that
if
we
will
not
cover
some
items
from
the
consensus
layer
part,
it
will
be
okay
because
it's
been
discussed
like
for
a
long
period
of
time
on
different
conversations
but
yep
the
main
focus
for
today,
the
application
layer.
So
let's
go
through
all
all
these
items
and
with
the
discussion,
but
before
we
start
I'd
like
to
turn
turn
to
proto,
to
make
an
announcement
about
iranism
support
organ.
B
B
B
We
have
these
four
new
routes
that
have
been
discussed
at
length
and
will
continue
to
try
it
on
and
then
on
the
epm2
side.
This
means
that
you
can
take
the
existing
phase.
Zero
implementations
modify
them
and
put
them
to
use
in
an
early
test
net
and
then,
after
it
gets
running,
we
can
take
our
time
for
production
prototype
where
we
can
think
about
the
fork.
Transition
implement
these
different
block
types
and
do
the
whole,
like
the
whole
implementation
work
for
the
actual
fork,
and
so
that's
all
that
these
are
the
essentials
for
a
multi-client.
B
Merge
does
not,
and
of
course,
there's
more.
We
could
do,
and
we
are
happy
to
support
this-
that,
like
we're
not
going
to
delay
an
early
test
not
far,
and
so,
if
you
can
get
this
running
quickly,
then
during
the
hackathon
we'll
have
this
opportunity
to
have
some
developers
on
our
test
net
with
the.
If
using
the
evm
on
proof
of
stack,
and
then
we
have
a
working
network
to
test
later
production
card
against.
B
I
hope
we
can
stabilize
on
some
specification
that
we
can
have
the
later
more
complete
clients
test
against
and
then
we'll
stabilize
the
essentials
like
the
rpc
unblock
sharding
prototyping.
So
the
idea
is
that
some
of
us
like
to
take
this
further
and
implement
these
experimental
things
like
sharding
and
then
having
this
very
minimal
base.
A
D
C
B
D
E
E
And
the
the
meta
the
primary
goal
is
to
like:
have
teams
just
have
someone
or
multiple
people,
kind
of
dig
in
understand,
specs,
understand,
complexity
of
this
project
and
how
things
kind
of
fit
together
and
also
kind
of
feed
back
into
the
process
of
specifications,
so
that
we
can,
you
know,
come
in
may
end
of
may
like
have
a
really
ironed
out.
Spec
and
roadmap.
F
B
C
A
Okay,
so
I
guess
we
can
move
on
right,
so
yeah
the
application
layer
discussion.
There
is
a
dock.
This
is
the
high
level
design
document
rather
than
the
spec.
It
tries
to
give
a
holistic
view
on
the
consensus
upgrade
from
the
application
node
or
from
the
mainnet
perspective,
so
yeah,
and
I
would
like
just
to
go
through
the
main
sections
of
this
document
and
stop
for
discussion.
A
A
D
E
I
would
say
that
the
the
way
that
these
two
specs
are
written
are
kind
of
they're,
very
beacon
chain
centric
and
our
implementers
are
very
familiar
with
understanding
that,
and
so
we
could
add
additional
notes.
I
think,
to
flesh
that
out,
but
I
don't
think
there's
like
an
immense
value
for
that
and.
D
I
think
right,
like
the
challenge
that
I
think
is
that,
like
we
don't
want
to
have
a
imbalance
between
levels
of
specificity
like,
as
is
there
even
like,
like
what?
What
would
you
say
is
the
doc
the
for,
like
the
the
corresponding
thing
right
now
for
the
consensus
lawyer
perspective,
that
covers
like
say
the
transition,
condition
and
beacon
block
changes,
and
those
things
like
is
that.
E
G
E
A
So
what
one
party
is
doing,
then,
what
the
expectation
like
from
the
application
layer
and
what
consensus
there
is
doing
at
this
moment,
so
that
would
make
a
lot
of
sense
to
give
the
and
the
understanding
of
the
whole
process
so
yeah,
but
rather
than
the
spec
in
the
beacon
in
these
two
specs
repo.
I
think
we
like
don't
have
anything
more
recent
in
regards
to
that
yeah,
okay,
so
yeah.
I
think
we
can
start
with
like
new
block
format.
Yeah.
There
is
like
the
interaction
between
the
consensus
and
application
layers.
A
It
has
like
four
messages,
but
I
would
start
from
the
we
can
get
back
to
this.
Like
interaction,
I
would
just
start
from
the
new
blog
format,
because
it
looks
like
a
simple
thing,
so
yeah
there
could
be
debates
about
extra
data
and
so
forth,
but
what
was
proposed
is
to
just
set
a
bunch
of
fields
that
are
related
to
the
proof-of-work
consensus,
to
the,
if
hash
just
set
to
some
constants
and
keep
them
on
entirely
on
the
application
layer.
A
In
the
application
block
and
what
will
what
is
going
to
be
exposed
to
the
consensus
to
the
beacon
block
body
is
the
like
the
actual
block,
the
actual
main
net
block,
with
the
with
all
these
fields
just
thrown
away
so
and
what
will
be
on
top
of
that
is.
The
block.
Hash
is
the
hash
of
this
block,
so
it
implies
that
the
application
layer,
once
it
gets
the
new
application
payload
from
the
consensus
part,
will
assemble
a
block
and
check
that
this
block
is
assembled
correctly.
A
With
regard
to
these
constants
by
checking
the
the
hash
of
this
block
is
equal
to
the
one
that
is
given
by
the
consensus
part
also
worth
mentioned
that
the
consensus
and
application
block
trees
are
has
a
one
one
to
one
mapping.
So
every
like
beacon
block
has
the
reflection
in
the
application
chain
and
all
the
forks
of
the
like
beacon,
beacon
chain
are
reflected
in
the
application
chain
as
well.
But
the
beacon
chain
is
the
primary
one
here
and
the
application
chain
is
secondary,
yep.
So.
H
A
E
E
H
H
H
A
E
But
it's
still
like
it's
it's
like
if
you
did
a
proof
of
work
on
an
invalid
block
that
is
going
to
be
gossiped
around
the
network,
but
then
it
would
be
quickly
dropped
because
the
like-
and
they
would
be
seen
as
invalid
and
there's
a
huge
opportunity
cost
in
in
doing
so.
So
it's
kind
of
like
the
analog.
H
H
A
I
E
H
D
Actually
one
one
quick
question
here:
so
when
a
beacon
chained
client
passes
a
block
to
an
applicant
to
the
application
client
like
over
that
wire
is,
it
is,
is
the
intent
for
it
to
still
be
in
us
in
a
ssd
form
or
in
like
a
list
of
fields
form
or
is
the
intent
for
it
to
already
be
an
rlp
form?
It's
like
a
json
payload
at
that
point,
right.
C
I
J
Just
a
quick
note
for
non-devs
who
may
be
watching
the
recording,
I
guess
there's
a
slight
abuse
of
notation
when
we
talk
about
consensus,
layer
and
application
layer
like
traditionally
the
application
layer
is
what
you
think
of
uni
swap
and
maker
and
all
the
dapps
in
this
case.
For
us,
the
application
layer
is
kind
of
the
evm
layer.
So
it's
the
management
of
the
evm
mempool,
the
management
of
the
evm
states
and
and
and
all
the
execution
layer.
And
then
the
consensus
layer
is
just
the
beacon
chain
layer
and
the
proof
of
stake.
G
A
H
A
E
A
I
A
A
Right
and
I
guess
well,
if
the
consensus
layer
will
check
the
block
numbers
right,
that
they
are
consecutive
and
check
the
parent
hash
that
is
matching
the
head
of
the
the
previous
head
of
the
chain,
so
the
geth
will
do
the
same
checks
actually
and
check
the
guest
limit
formula
so
yeah.
That
makes
sense.
I
mean
to
do
in
both
sides,
so
it
doesn't
take
much
computation
resources,
yeah,
okay,
so
some
particular
fields.
A
J
I
E
I
Yes,
there's
one
slight
detail,
for
example,
if
if
I
just
start
on
the
eth1
client,
then
the
iphone
client
needs
to
wait
for
these
two
client
to
do
something.
Otherwise
it's
just
idling.
So
it
cannot
initiate
any
actions
which
means
that
I'm
I
must
wait
for
a
new
head,
rpc
call
and
just
wait
until
then,
so
I
don't
have
the
capability
to
just
tell
these
to
client
that
hey,
I
just
crashed.
I
just
recovered.
Give
me
a
head:
that's
not
necessarily
a
problem
and
I'm
just
again:
it's
just
exploring
the
design
yeah.
I.
I
G
C
I
E
I
A
A
It
should
be
some
kind
of
status
message
or
ping
or
whatever
or
yeah,
or
we
can
put
a
response
into
one
of
these
messages,
because
they
will
be
frequently
sent
by
the
consensus
layer,
like
the
block
on
your
head,
that
the
obligation
crashed
and
act
accordingly
on
the
consensus
part
so
yeah.
But
I
think
that
this
is
the
like
implementation,
details
more
so
and
for
consensus
purposes
for
for
chain
management
purposes
like
this
unidirectional
channel
should
be
enough
to
go
with.
I
Yes,
so
just
one
sorry
and
keeping
the
rear
in
this
discussion,
so
although
it
seems
like
an
implantation
detail,
the
reason
I
kind
of
want
to
highlight
that
it's
not
necessarily
because,
for
example,
synchronization
code
or
events
that
we
react
upon,
they
also
depend
on
what
we
can
do.
So
it's
not
just
something
internal,
it
kind
of
some.
What
drives
synchronization
to
it,
and
it's
essentially,
we
can
do
it
either
way.
So
it's
there's
no
good
or
bad
solution,
because,
obviously
I
know
design
will
work.
A
A
I
think
it
makes
some
some
sort
of
sense
on
the
like
network,
but
let's
not
go
into
details
like
it
would
make
sense
to
keep
the
difficulty
increasing
for
the
probably
if
status,
message
and
that
is
sent
by
the
application
client
and
by
current
ethereum
client
one
once
it
starts
and
connects
to
the
other
peers.
So
I
think
we
can
not
like
focus
on
this
now
so
time
stamp
time
stamp
will
be
when
we
communicate
it
from
the
consensus
part.
E
D
H
Sure
to
take
a
step
back
currently,
when
you
are
a
block
author,
you
are
rewarded
with
east
fees
and
I
don't
actually
know
if
that
happens
at
the
beginning
of
the
block
or
the
end
of
the
block.
But
you
definitely
can
spend
them
as
soon
as
the
next
block
happens,
and
is
that
changing
with
when
we
move
the
consensus
and
therefore
block
rewards.
H
H
D
C
H
I
So
I
just
wanted
to
highlight
something
I
I'm
guessing.
Most
clients
are
already
capable
of
it.
So
essentially,
once
we
set
the
block
subsidy
to
zero,
or
maybe
even
with
1559
on
mainnet,
an
interesting
thing
happens
that
all
of
a
sudden,
you
can
have
blocks
multiple
blocks
having
the
same
state
root
hash.
I
This
currently
on
mainnet
is
impossible
because
the
ether
is
always
accumulating,
so
you
cannot
have
repeating
hashes,
but
this,
for
example,
can
happen
on
click
networks
like
gurley
and
winkabi,
and
it's
a
pain
in
the
ass
to
always
make
sure
that
the
clients
handle
it
correctly.
So
I
just
wanted
to
emphasize
that
once
we.
C
I
I
H
D
D
E
One
more
kind
of
related
follow-up
is
that
the
if
you
have
the
the
overlay
beacon
chain-
and
you
have
this
kind
of
application
chain
embedded
inside
of
it
the
application
chain.
I
think
at
this
point
in
this
current
design
could
have
two
branches
that
have
the
same
roots
at
the
end
of
them,
because
you,
essentially
you
don't
have
this
proof
of
work.
You
don't
have
the
nonce.
You
can
have
the
same
application,
payload
on
two
different
branches
from
the
same
parent,
and
so
there
we
said
there's
like
a
one-to-one
relationship.
E
E
Because
if,
if
the
beacon
chain
says
that
head
to
this
and
set
head
to
this
from
the
layer
from
the
perspective
of
the
application
layer,
it's
like
it's
totally
it's
the
same
thing.
It's
just
the
vegan
chain
can
be
consensus
on
the
same
state
in
terms
of
the
application
layer.
So
again,
that's
probably
actually
not
much
of
a
design
issue.
A
It
just
means
that
there
is
no
more
total
difficulty
focus
rule
and
the
the
application
layer
tracks
the
messages
from
the
consensus
about
not
notifying
that
there
is
a
new
head
and
it
must
do
the
rework
or
to
not
the
real
work
if
it's
not
needed
according
to.
What's
you
had
to
the
observation
of
the
consensus,
there
is
currently
eased.
I
In
in
theory,
it
it's
okay
as
long
as
one
specific
condition
holds,
and
actually
that
was
my
question
so
by
setting
the
difficulty
to
one-
that's
actually
nice,
because
we
can
still
track
the
longest
chain.
The
question
is:
can
it
happen
that
the
beacon
chain
will
tell
me
that,
up
until
now,
I
had
a
chain
of
three
blocks
and
the
new
head
will
be
block
number
two
on
the
side
chain?
I
D
I
Okay,
so
the
reason
I
was
asking
is
because,
at
least
in
gas,
the
whole
synchronization
and
block
propagation
is
a
lot
of
ugly
complexity
is
due
to
handling
these
reorgs
and
side
forks
and
whatnots,
and
at
least
from
synchronization
perspective.
Things
can
get
a
lot
simpler
if
we
don't
expect
rears.
Of
course
we
need
to
handle
it,
but
it's
one
thing
to
handle
it
as
a
special
occasion
that
happens
once
a
day
or
once
a
week
and
it's
other
to
handle
it
five
times
per
minute.
K
K
I
E
Yeah
another
thing
that
kind
of
fits
into
there
is
that
you
have.
You
also
have
this
notion
of
finality,
which
becomes
kind
of
a
natural
place
to
do
sort
of
state
cleanups
and
pruning
things,
whereas
I
know
that's
probably
now
handled
as
fixed
step.
So
that's
something
to
consider
is
that
you
would
maybe
only
do
those
actions
upon
signal
from
speaking
know
that
there
was
finality.
A
Okay,
okay,
okay,
so
the
folk
choice,
yeah,
pretty
simple.
This,
like
second
condition.
Second,
second,
like
approach,
then
you
can
update
the
head
like
like
if
the
new
block
is
the
ch,
the
child
of
the
current
like
chain
hat.
So
this
is,
I
guess
this
is
the
implementation
detail
that
might
be
taken
or
not
so
yeah.
The
main
message
here
is
the
new
hat.
So,
okay,
anything
here
before
we
move
to
the
network
part
anything
that
probably
missed,
and
we
want
to
discuss
by
the.
K
A
I
A
Yeah
so
yeah
and
these
two
messages
are
causally
dependent.
So
then
you
block
a
new
head
must
be
processed
sequentially
as
they
come
to
avoid
weird
case
when
the
new
head
points
to
the
new
block
that
hasn't
been
yet
persistent
and
the
the
like.
From
the
sender
perspective,
they
will
be
consistent
from
the
beacon
chain
perspective,
because
new
head
won't
point
to
the
like
the
block
that
hasn't
been
yet
persist.
A
A
It
should
be
like
deprecated
and
we
we
can
like.
We
are
now
talking
about
the
like.
If
just
imagining
that
the
merge
has
happened
some
like
some
few
epochs
ago,
and
it's
completely
like
proof
of
stake
mode,
we
can
touch
like
this
corner
cases
in
the
transition
process.
Later
transition
process
is
like
complicated.
A
Yep
has
a
lot
of
edge
cases
and
yeah.
So
the
block
gossip
just
doesn't
work
yeah.
That's
because
the
application
layer
doesn't
know
about
the
beacon
state
about
validators,
and
it
just
can't
verify
that
the
block
is
eligible.
That
seal
is
correct,
and
so
that's
that's
handled
completely
by
the
beacon
chain.
After
the
match.
A
A
The
only
like
the
big
change
here
is
that
the
application
layer
will
know
what
the
head
of
the
chain
is,
what
the
current
head
of
the
chain
is,
and
it
will
be
able
to
start
download
the
state
upon
receiving
this
new
block
and
new
head
so
request,
like
new
block,
will
contain
the
state
route.
The
new
head
will
say
that
this
is
the
head.
A
So
let's
just
start
download
this
state
with
that
yeah
with
this
state
route,
the
chain
history,
data
which
are
headers
bodies
and
receipts,
it
would
make
sense
to
wait
until
the
block
is
gets
finalized,
and
it
will
mean
that
there
is
one
chain
between
janus
starting
from
genesis
and
ending
up
with
this
finalized
blog.
So
it
makes
sense
to
not.
A
You
know
to
not
to
to
wait
for
this
event
to
get
rid
of
the
fork
management
during
the
sink
and
just
go
backward
as
it
is
now
in
the
fasting
download
headers.
The
whole
bodies
receipts
so
for
us
so
and
yeah.
One
additional
thing
here
is
that
there
is
no
need
to
verify
the
heat
hash
anymore,
because
it's
proved
by
the
proof
of
stake.
Consensus
of
the
previous
chain
and
yeah
and.
E
Meaning,
when
you're
doing
when
you,
if
you're
handling
kind
of
historic
blocks
prior
to
the
merge
that
have
any
hash,
you
don't
have
to
validate
it,
because
the
chain
would
be
finalized
on
proof
of
stake.
Side
invested
as
a
chain
with
a
known
head
and
consistency
of
that
chain
is
all
you
really
need.
A
Right,
the
question
is:
do
I
understand
correctly
that
the
state
downloader
is
just
you
know,
bootstrapped
with
some
state
routes
that
is
taken
from
the
wire
from
the
observation
of
the
network
and
then
constantly
update
it
with
the
new
state
routes,
as
the
new
block
and
or
new
block
hash,
a
new
block
coming
from
the
y?
Is
it
correct.
I
Yes,
almost
correctly,
it
doesn't
get
updated
every
time
the
the
chain
progresses,
because
that
there
are
about
a
few
thousand
modifications
in
every
block,
so
it
would.
It
would
keep
downloading
data
that
will
get
go
stale
in
14
seconds.
So
currently,
what
we
do
is
if
the
route
gets
older
than
128
blocks
and
that's
the
threshold
for
which
get
maintains
the
state.
I
Yeah,
I
just
wanted
to
highlight
that
yes,
there's
actually
probably
not
a
good
idea
to
mix
in
the
finalization
into
it,
because
tracking
a
few
tiny
forks
on
the
head
of
the
chain
is
fine.
So
if,
if
I
have
to
download
12
million
blocks,
it
doesn't
really
matter
whether
the
top
two
or
three
blocks
keep
reworking
each
other.
That's
going
to
be
fairly
trivial
to
maintain
or
to
manage
and
the
finalized
block.
I
don't
know
how:
how
deep
is
the
finalization
layer
currently
how
many
blocks
64
blocks?
Sorry.
E
I
I
C
A
Okay,
so
the
sync
is
in
process
and
there
is
need
there
is
a
need
to
like
notify
the
consensus
lawyer
that
the
sink
is
done
so
like
what
I
propose
is
just
to
you
know,
have
like
more
rich
status
for
each
new
block
message,
but
probably
it
looks
like
a
crutch
here
so,
but
that
makes
sense,
because
if
the
application
node
is
able
to
execute
a
block,
then
it
means
that
this
thing
is
finished.
So
probably
it
was
doing
it.
A
G
C
G
I
G
G
I
L
L
A
L
G
Yeah,
just
a
tiny
addition
that
I
think
that's
what
we
said
about
the
new
block,
it's
true
when
we
already
caught
up
to
to
the
head,
but
we're
we
initially
thinking.
I
guess
we
still
need
to
just
it
won't
be
gossiped,
but
we
still
need
to
like
proactively
download
it
from
the
blocks
from
the
other
peers
from
the
application
layer
right.
If
we
just
got
a
new
head
and
we
have
like
zero
state,
then
it's.
I
H
G
A
D
D
Data
voting
is
an
honest
majority
thing,
but
eventually
we
would
want
to
get
rid
of
that
mechanism,
and
so
I
guess,
like
the
validation,
might
have
to
be
redone
a
bit
like.
First,
you
would
sync
the
consensus
chain
and
if
and
if
the
application
chain
isn't
verified
yet,
then
you
would
just
like
take
the
deposit,
the
deposit
routes
on
the
trust
and
then
and
remember
them
and
then
later
on.
When
you
get
the
application
chain,
you
would
check
that
everything
matches
up.
E
E
D
E
H
Hypothetically,
could
someone
running
a
consensus
client
who
didn't
want
to
or
couldn't
for
whatever
reason
run
an
application
client?
Could
they
produce
empty
blocks?
If
their
turn
came
up
like
you
actually
need
a
full
application,
client
to
produce
a
block
or
you
just
need
something
that
can
give
you
a
thing.
That's
shaped
like
a
block.
C
I
C
I
By
the
way,
just
to
go
back
to
the
previous
note
previous
question,
I
think
the
question
was
whether
the
the
beacon
chain
or
the
consensus
chain
needs
to
be
able
to
sync
without
the
application
layer,
and
I
think
that
would
be
a
hard.
Yes,
I
mean
you
can
debate
the
trust
model,
but
the
thing
is
that
the
expectation
is
that
the
state
try
will
only
be
available
for
the
head
few
blocks,
maybe
head
64
or
128
blocks.
C
E
C
A
I
I
A
I
think
there
you
go
okay,
so
something
where
it
happened,
happened,
okay,
so
it
could
be
hybrid
strategy
when
the
application
now
starts
up
and
starts
sinking
blocks
from
the
first
block
and
at
the
same
time,
the
consensus
layer
catch
up
with
the
head,
communicate
this
hat
to
the
application
layer
and
the
sinking
forward
and
downloading
the
headers
in
reversed
order.
Then
this
chain,
these
two,
like
downloading
processes,
converge
at
some
point
and
then
goes
forward.
So
it's
also
like
an
option
here.
A
I
To
go
horribly
wrong
and
then
you
would
need
to
check
the
proof
of
work,
and
if
you
run
out
of
proof
of
works,
then
you
cannot
verify
anything.
And
the
other
thing
is
that
if
currently,
the
proof
of
work
chain
is
kept
alive
because
everybody
is
keeping
mining
proof
of
works
on
top.
But
once
once
the
head
is
directed
by
proof
of
stake.
Essentially
I
can
mine
an
alternative
reality
for
ethereum.
That
is
heavier
than
the
original
ethereum.
I
M
You
don't
have
a
very
high
profile,
stay,
a
proof
of
work
because
you're
going
downwards
and
you
always
have
information
about
the
parent
hash.
So
when
you,
when
you
receive
the
hat
from
the
proof
of
stake
chain,
then
you
have
information
about
the
parent
house,
you're,
always
verifying
the
parent
hashes
and
at
some
point
you
reach
genesis,
which
means
that
you
are
sure
that
you
you
reach
the
same
genesis
as
you
would
be
in
the
normal
chain.
It's
actually
how
we
currently
synchronize
the
mind.
So
so
it's
exactly
the
same
behavior
as
you
have
currently.
H
I
A
G
A
M
So
I
have
a
question
about:
do
we
consider
here
any
adjustments
to
where
the
bodies
are
stored?
Like
did
you
consider
discussing
that
also
with
this
idea
that
comes
from
piper
steam
at
trinity
on
the
dht
around
block
bodies,
because
block
bodies
are
quite
heavy,
so
they
take
like,
I
believe,
150
gigs
nowadays
and
they
take
a
bit
longer
to
download.
M
E
A
Okay,
so
the
transition
process,
the
like
the
complexity
of
this
process,
comes
with
the
requirement
for
the
software
to
like
be
able
to
operate
in
these
three
modes.
So
the
software
like
the
client
will
be.
You
know,
updated
like
with
some
some
decent
amount
of
time
before
the
merge
before
the
like
potential
point
of
the
match,
and
then
it
will
have
to
operate
in
the
proof-of-work
mode,
for
unless
the
transition
conditions
are
met,
then
transition
mode
comes
where
the
like.
A
C
A
C
A
E
Would
be
penalized
slowly,
you
know
they
would
stand
to
lose
about
as
they
stand
to
make
so
like.
If
they
were
on
that
orphan
chain
for
a
year,
they
would,
you
know,
lose
eight
nine
percent
of
their
their
stake
and
yeah
it's
similar
to
what
would
happen
today.
You
know
if
75
of
the
miners
were
on
client.
A
and
25
percent
are
on
client,
b
and
client
b
disagreed.
E
So
that's
something
to
consider
so
like
two
epochs
after
this
chain
break
things
would
likely
finalize,
which
would
be
a
much
stronger
signal
than
say
just
a
proportion.
But
even
then
it's
definitely
a
catastrophic
scenario.
For,
depending
on
how
much
of
the
network
is
on
that
and
should
be
avoided
similar
today,.
M
A
Okay,
so
the
transition
process
like
on
the
consensus
layer,
looks
like
as
follows.
So
there
is
the
total
difficulty
is
a
certain
value
for
the
total
difficulty
and
once
it's
reached
by
the
mainnet,
the
beacon
chain
will
like
track
all
the
blocks
from
the
main
net.
So
it
will
already
be
a
combined
client
with
the
beacon
chain
and
the
with
beacon,
node
and
the
application
node,
which
the
application
node
is
still
operating
on.
A
The
proof
of
work
conditions
and
once
detailed
difficulty
met
the
consensus
layer
we'll
take
this
block,
this
last
proof
of
work
block
and
build
a
block.
The
first
proof
of
stake
block
on
top
of
this
one
and
yep
communicate
this
to
the
application
layer.
So
it
will
send
this
block
in
a
new
block
message
and
then
in
the
new
head
will
be
sent
accordingly.
A
So
and
once
the
application
now
receives
these
message
messages
it
turns
to
the
external
factors
rule
and
starts
following
these
messages
from
the
consensus
layer,
there
will
be
also
a
sample
block
for
some
cases
when
you
will
have
to
produce
a
block.
So
so
it's
eligible
for
the
report
mode
as
well,
and
then
after
some
time,
the
finalized
block
for
the
first
finalized
block
message
is
called,
and
then
the
application
node
understand
that
this
is
the
time
to
turn
off
the
block,
gossip
and
turn
to
the
proof
of
stake
mode.
G
Yeah
just
a
question
so
basically,
if
you're
in
proof
of
work
mode,
then
if
you've
been
choosing
as
a
blog
blog
proposer
on
the
beacon
chain,
then
you
will
receive
assemble
block.
If
you've
been
choosing
as
a
block
validator,
then
you
will
receive
a
new
block
and
the
rest
will
receive
a
new
head
right
when
the
first
block
is
being
proposed.
A
I
A
A
D
C
A
I
A
I
D
I
just
the
the
idea
is
that,
like,
while
the
transition
is
not
finalized,
there
is
still
the
possibility
of
the
beacon
chain
reorganic
to
a
different
beacon
chain
that
has
a
new
first
embedded
block
and
to
check
that
different,
first
embedded,
blog,
like
that,
first
embedded
blog,
would
have
a
proof
of
work
parent
and
that
proof
of
work.
Parents
like
could
potentially
be
well,
would
be
mined
and
it
could
potentially
be
mined
at
some
point
later,
and
so
you
still
need
the
ability
to
keep
broadcasting
them.
D
I
E
Could
even
probably
not
you
could
even
restrict
proof
of
work
block
gossip
such
that
you
only
broadcast
blocks
that
are
past
the
total
difficulty
of
one
by
one
block
and
no
further
children
on
such
chains,
because
the
only
valid
blocks
to
include
on
the
proof
of
stake
side
would
be
like
that.
First,
child
passed
the
total
difficulty
or
depending
on
how,
if
you're
doing
greater
than
or
equal
to
just
right
at
that
threshold.
I
A
So
the
first
proposer
of
the
proof-of-stake
block
with
embedded
application
payload,
will
get
its
head
of
the
proof
of
work
chain
proof
of
work
chain
and
asked
to
assemble
a
block
on
top
of
it,
yeah
yeah
and
it
might
not
be
the
head
for
the
rest
of
the
network,
but
until
this
block
is
valid
until
this
proof-of-work
block
this
last
work
block
is
valid
and
mets
meets
the
transition
conditions.
Then
everybody
is
okay
with
that.
So
it's
valid.
A
So
if
you
started
this
client,
it
will
need
to
be
designed
in
a
way
that
it
can
handle
everything
correctly.
So
the
merge
happened,
but
it
doesn't
know
about
it
yet,
so
it
will
need
to
take
this
information
from
the
network,
but
I
don't
see
any
big
issues
with
that,
but
yeah
definitely
worth
to
think
that
through
and
what
and
after
some
time
you
know
some
after
some
time
of
the
merge,
I
guess
the
clients
will
just
throw
away
this
transition
process
from
the
code
base
and
yeah
just.
C
A
Yeah,
so
that's
I
guess
it
could
be
an
implementation
detail,
so
you
may
have
this
flag
right
if
you
know
that
the
merge
has
happened.
But
if
you,
if
you
don't
know
for
some
reason
you
you
can
start
operating
the
proof
of
work
mode
and
then
once
the
some
message
comes
from
the
proof-of-stake
like
new
block
and
you
had,
you
can,
like
you
know,
readjust
your
mode
yeah
node.
Can
the
client
can
readjust
its
mode.
I
I
I
don't
know
how
much
time
it
takes
for
the
e2
client
to
sync
up,
but
up
until
that
point
the
e1
client
will
do
weird
things
I
mean
I
will
start
downloading
the
state
route
for
something
that
might
be
completely
invalid
because
right,
maybe
some
miner
remained
on
the
original
chain
and
didn't
fork
off,
and
then
they
are
just
advertising.
Some
weird
states
that
I
will
actually
sink
to
or
try
to
sync
to
up
until
the
point
where
the
proof
of
stake
note
says
that
hey.
C
C
A
Yeah
yeah
and
you
can
like
add
the
block
hash
for
the
first
proof
of
stake
block.
You
know
so
just
to
er
the
same
way
they
dial
hard
fork
block
has
been
handled
on
the
network
if
it
helps,
but
it
it
requires
some
intervention.
You
know.
So
this
is
the
same
to
say
that
the
merge
has
happened.
You
know
it
requires
some
intervention
from
the
user.
I
G
Yeah
I
mean
if
it's
still
required
to
sync
that
all
the
old
like
proof
of
work
chain,
then
I
think
it
makes
sense
after
the
merge
to
make
a
kind
of
release,
that's
kind
of
hard
codes,
the
block
and
maybe
the
root
hash
of
the
last
proof
of
work
block
and
just
start
syncing
to
this
block.
Immediately,
because
why
not?
Even
though
proof
of
stake
might
not
be
synced
yet
because
you
will
know
aft
after
the
merge
actually
happens,.
I
E
G
A
A
H
So
would
it
be
reasonable
to
assume
that,
given
the
most
pathological
situation,
where
miners
are
running
some
custom
code
towards
the
end
that
we
should
expect
to
see
many
many
peers
of
the
last
block?
So
we
will
just
see
like
assuming
miners
are
running
like
no
client
that
was
going
to
code
this,
but
as
we
miners
all
write
their
own
code,
the
rational
thing
for
them
to
do
would
be
to
just
repeatedly
mine
that
last
block
over
and
over
and
over
again
right.
H
E
A
E
Also,
not
very
incentivized,
because
once
the
beacon
chain
picks
a
block
to
build
on
and
there's
at
the
stations,
it
quickly
becomes
very
difficult
to
reorg
that
the
beacon
chain,
the
the
miner,
can't
do
anything
to
reor.
You
can
change
that
point
to
try
to
get
their
new
head
around.
That
point
picked
in.
A
A
I
So
I
personally,
for
me
this
is
fairly
clear.
I
mean
the
exact
format
of
these
assemble
block,
new
block,
rpc
methods.
They
don't
really
matter
so
whoever
writes
up
an
initial
spec.
I
think
we
can
run
with
it.
I
think
there's
already
an
initial
implementation
in
catalyst,
so
I
don't
think
if
there's
a
need
to
detail
it
too
much.
I
I
J
G
I
F
E
C
I
C
I
I
I
I
E
I
I
A
A
Also,
there
is
like
a
question
or
proposal
like
to
yeah
virtual
for
total
difficulty,
value
transition,
d
plus
slot
number.
It's
not
gonna
work
because
the
in
the
beacon
chain,
the
block,
is
not
self-sufficient
in
terms
of
fork
choice,
because
it's
a
test
later
and
could
better
sit
later
and
at
the
station
could
be
included
on
chain
like
one
slot
after
and
it
can,
it
affects
the
item.
It
has
an
impact
on
the
folk
choice,
so
virtual
total
difficulty
will
not
work
in
this
case.
A
D
A
Okay,
thanks
alex
thanks
everybody
for
this
great
discussion
yep.
I
I'm
happy
that
we
go
went
through
all
these
documents
and
even
happy
that
we
didn't
cover
other
aspects
of
the
agenda.
Well,
it
can
be
due
later
on
the
subsequent
call.
So
this
call
is
bi-weekly,
so
anybody
who
wants
to
have
an
invitation-
let
me
know
just
dm
your
email
address,
so
see
you
tomorrow
on
the
elkor
death,
school
and.