►
From YouTube: PEEPanEIP#50: Merging Ethereum with Paul Hauner
Description
Topics covered
-----------------------------
1:45 - Guest’s introduction
3:50 - Merging Ethereum
4:40 - The Merge: An Overview
5:12 - EIP-3675: Upgrade Consensus to Proof of Stake
7:00 - One chain…. With a sneaky inside chain
7:43 - Why sneaky chain - Reason 1: existing tooling & dependencies
8:39 - Reason 2: no need to implement the wheel
9:29 - Chain structure
9:50 - Terminology
13:10 - Moar terminology
13:57 - Data structure
15:44 - Producing a beacon block - Block production
20:38 - Producing a block - what have we learned?
22:14 - Processing a beacon block - block processing
26:10 - Processing a block - what have we learned?
29:39 - The Merge Infrastructure
35:32 - The Merge: Syncing
36:10 - Lockstep syncing
39:33 - Optimistic syncing
54:34 - The Merge: Progress so far
54:44 - Amphora workshop
55:54 - The ultimate goal- multi client merge devnet
57:30 - Milestones
1:00:25 - Pithos testnet
01:01:44 - Merge engineering standing
01:04:56 - Guest’s contact
01:05:38 - Question - Explain the interop combination of EL & CL clients?
01:07:49 - What is the proposed way forward for CL clients to deal with the uncertainties listed in the “Optimistic post-merge sync” at GitHub?
01:11:43 - Is there any concern about delivering at the proposed time?
Resources
--------------------
Slides - https://docs.google.com/presentation/d/1Y6Eth-9PEFX313QEtICZX2OT_Ua8XGTXjd5l4cx76Sg/edit?usp=sharing
Optimistic post-merge sync - https://github.com/sigp/lighthouse/issues/2691
EIP-3675: Upgrade consensus to Proof-of-Stake with Mikhail Kalinin -https://youtu.be/zNIrIninMgg
https://hackmd.io/@tvanepps/amphora-milestones
https://notes.ethereum.org/@djrtwo/BJxKBaqNF
Follow at Twitter
-----------------------------------------------
Paul Hauner @paulhauner | William Schwab @William94029369 | Pooja Ranjan @poojaranjan19
Contact Ethereum Cat Herders
---------------------------------------------------
Discord: https://discord.io/ethereumcatherders
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
Hello
and
welcome
to
the
50th.
That's
right.
The
50th
episode
of
t
penny
an
educational
video
series
where
we
learn
about
an
improvement
proposal,
upcoming
upgrades
and
the
basics
of
ethereum
blockchain,
I'm
puja
ranjan
super
excited
to
host
this
golden
episode,
hard
to
believe
it's
been
over
a
year
since
we
started.
A
A
A
B
Oh,
I'm
supposed
to
have
a
presentation
ready,
that's
right,
so
my
name
is
paul.
I've
been
a
software
developer
for
professionally,
maybe
10
12
years
or
something
I
originally
worked
in
control
systems,
so
controlling
motors
and
projectors
and
lights
and
audio
visual
things
like
this.
I
got
sucked
into
ethereum
in
about
2015.
I
believe
around
the
crowd
sale
time
had
seen
bitcoin
before
didn't,
find
it
that
interesting.
We
found
ethereum
really
fascinating,
so
I
started
getting
involved
in
the
sydney
ethereum
meetup
community.
B
A
couple
of
my
friends
were
also
involved
and
we
went
to
devcon
2
in
shanghai
and
then
from
there
started
sigma
prime
as
a
bit
of
a
side
hustle,
and
that
was
about
almost
five
years
ago
now
we
started
sigma
prime.
So
since
then
we
started
doing
a
little
bit
of
smart
contract
security
auditing,
which
the
super
prime
does
a
lot
of
now
myself.
B
Personally,
not
so
much
grew
the
company
through
that
and
then
eventually
got
involved,
contributing
to
the
open
source,
ethereum
proof
of
stake
movement
and
then
yeah
lighthouse
started
producing
a
rust
implementation.
Sorry,
sigma
prime
started
producing
a
rust
implementation
of
the
current
specifications.
B
Then
we
called
the
lighthouse
because
it
was
kind
of
like
a
rusty
beacon
for
the
rust
and
the
beacon
chain,
and
then
since
then,
it's
grown
into
a
big
project
with
a
bunch
of
maybe
order
of
10
10
people
on
it,
many
lines
of
code
and
many
users,
many
billions
of
funds
staked.
So
yeah,
that's
a
that's
a
rough
history
of
me.
C
B
A
B
All
righty
I'll
just
get
my
presentation
started
all
right.
So,
let's
get
started
today,
I'm
going
to
be
talking
about
merging
ethereum,
so
originally
there
was
that
this
was
kind
of
filled
to
be
about
altair,
but
I
started
talking
about
the
merge
and
there's
just
so
much
to
talk
about
that.
I
thought
I'll
just
go
all
with
the
merge,
plus
else,
there's
at
a
point
now,
where
in
about
a
bit,
maybe
a
bit
over
24
hours,
the
fork's
going
to
happen.
So
I
feel
like
if
we
waited
48
hours.
B
We'd
have
a
whole
lot
more
to
talk
about
without
there.
So
this
one
is
just
about
merge.
I
hope
that's
okay
with
everyone,
so
I
think
we've
seen
a
little
bit
about
myself
already
sigma
prime,
is
where
I
work.
The
whole
company
is
about
20
people,
the
restaurant
are
doing
information,
stuff
information,
security,
stuff.
We
work
very
close
with
the
ethereum
foundation
and
also
a
few
other
blockchains
barclaying.
B
So
gonna
be
a
few
parts
of
this
talk
to
the
first
one.
I
want
to
give
an
overview
of
the
merge
just
to
give
people
a
bit
of
an
idea
of
what's
happening,
the
mechanics
involved.
So
very
very
briefly.
The
idea
is
to
replace
proof
of
work
with
proof
of
stake.
There's
a
few
reasons
we
want
to
do
this.
One
is
the
environmental
reasons,
as
my
emoji
suggested,
and
the
other
is
for
security
reasons.
B
B
There's
already
been
people
need
to
talk
about
this
by
mikhail.
It
was
very,
very
detailed,
very
good.
He
went
through
the
specification,
so
I
think
if
you
just
look
in
the
picnic
channel,
you'll
find
it
in
there.
So
what
I'm
not
going
to
do
is
go
through
that
that
in
in
fine
grained
detail,
but
what
I'll
do
is
I'll
kind
of
look
at
it
from
a
more
high
level
view
and
and
see
what
it's
like
for?
B
B
This
is
what
ethereum
is
now,
so
the
top
chain
is
proof
of
work
ethereum,
it's
what
everyone's
kind
of
known
as
ethereum,
it's
been
running
since
2015
or
whenever
it
started,
and
it's
proof
of
work
and
it's
a
chain
for
with
basically
a
little
bit
of
proof
of
work,
stuff
and
a
whole
bunch
of
transactions.
So
then,
in
december
2020
so
december,
last
year
we
launched
the
beacon
chain.
So
then
we
started
another
ethereum
chain
and
that
chain
just
has
staking
stuff
in
it.
So
it
doesn't
actually
do
any
transactions.
B
All
we
do
is
just
manage.
Validators,
give
them
rewards
and
penalties
for
being
good
and
bad.
So
the
idea
with
the
ip675
is
there
is
a
terminal
proof
of
workflow
so
that
that
chain
stops
and
then
from
there
the
beacon
chain
collects,
brings
in
the
transaction
stuff
into
its
blocks
and
then
from
then
on.
It
carries
on
with
both
shaking
stuff
and
transaction
stuff,
so
this
is
a
broad,
broad
overview
of
the
ip3675.
B
So
that
means
there's
going
to
be
one
proof
of
stake
chain
to
rule
them
all.
Does
it
not
not
necessarily
depends
how
you
look
at
it
so
from
a
broad
overview
we
do
have
just
one
chain,
so
if
you're
looking
at
it
from
the
outside,
perhaps
from
a
high
level
view,
you
can
see
that
just
this
one
chain
inside
the
blocks
is
stuff.
That's
managed
shaking
and
starts
to
manage
transactions,
but
if
we
have
a
look,
a
little
closer
inside
we've
actually
built
another
chain
inside
that
chain.
B
So
these
beacon
blocks
they're
going
to
have
shaking
stuff
those
blocks
reference
each
other,
and
then
the
transaction
stuff
actually
represents
references
a
chain
inside
itself.
So
why
did
we
do
this
sneaky
chain?
It's
not
to
you
know,
hide
a
pre-mine
or
anything
sinister
is,
for,
I
think
two
good
reasons.
So
the
first
good
reason
is
backwards,
compatibility
for
existing
tooling
and
dependencies.
So
ethereum,
as
we
know,
it
has
been
running
for
many
years
now
and
there's
a
lot
of
things
that
expect
there
to
be
this.
B
This
predictable
chain,
you
know
the
kind
of
chain
of
blocks.
If
you
look
on
etherscan
you'll
see
you
know
referenced
by
by
parent
hash,
each
block
where
it
has
a
has
a
root
of
the
state
three
and
then
there's
smart
contracts
that
use
the
evm
to
modify
that
state
3
and
all
of
these
apps
built
on
top
of
it.
B
Second
reason
is
because
we
already
have
a
whole
bunch
of
software
that
manages
that
chain
very,
very
well,
so
all
of
the
existing
ethereum
clients,
like
yes
eragon
nethermind,
they
all
do
a
great
job
at
managing
this
very
difficult
task.
That
is,
you
know,
maintain
this
chain
of
the
network,
storing
the
database
and
syncing
it,
and
also
with
this
reason
we
already
have
a
bunch
of
these
consensus-
clients,
ethereum
beacon,
chain
clients
that
do
a
great
job
at
the
proof-of-stake
stuff.
So
they
you
know
count.
B
You
know
tens
of
thousands
of
attestations
per
second
and
they
do
a
very
good
job
of
that
and
it's
quite
difficult
to
task
on
its
own.
So
the
idea
is
that
if
we
maintain
these
separate
chains,
then
we
can
use
the
different
bits
of
software
to
maintain
it.
So
a
little
bit
like
this,
so
with
this
new
chain
we're
going
to
let
the
existing
ethereum
clients
like
your
ethereum,
maintain
the
transaction
stuff,
so
they
can
keep
running
with
minimal
changes,
and
then
we
have
all
of
the
beacon
chain
clients.
B
B
So
now
all
the
stuff
that
I
was
calling
staking
stuff
we're
gonna
start
calling
the
consensus
layer.
So
this
is
all
about
coming
to
agreement
on
the
chain
which
chain
is
the
right
chain
which
which
box
would
be
discarded
validators?
How
many
rewards
they
get,
what
they
vote
on
things
like
that,
so
that's
all
the
consensus
player,
that's
something
that's!
This
is
lighthouse's
job
or
prison's,
job
or
nimbus's
job,
and
then
on
the
other
side,
we
have
execution
layer.
B
So
this
is
pretty
much
what
current
ethereum
is
now
it's
just
all
execution
layers.
So
this
is
yes,
it's
aragon.
All
these
clients
and
this
execution
layer
is
interested
in
processing
transactions
interested
in
maintaining
the
the
ethereum
states,
contracts,
states,
balances,
preventing
double
stems,
and
things
like
this,
so
we
have
the
consensus
layer
for
the
shaking
stuff
and
then
the
execution
layer
for
transaction
stuff.
D
B
Agreement
upon
it,
so
we're
kind
of
in
the
process
of
switching
to
this
new
consensus,
execution
stuff,
but
there's
still
still
a
few
players
out
there
that
are
into
f2
and
f1.
So
let's
go
over
them,
so
the
I
guess
existing
terminology
we
have
is
f1
and
f2.
This
came
about
sometime
before
the
beacon
chain
launched
in
december
2020,
so
I
guess,
prior
to
2018
or
2019,
we
just
had
ethereum
everything
was
ethereum.
B
Then
in
2018
vitalik
announced
that
ethereum
ii
specification
and
then
the
ethereum
2.1
specification.
We
all
forgot
about
2.1
just
called
ethereum
2..
So
the
idea
was
that
all
the
proof-of-stake
stuff
gets
called
ethereum,
2,
then
kind
of
by
default.
We
ended
up
calling
present
ethereum
ethereum
one.
So
there's
been
an
effort,
I
think
primarily
pushed
by
the
ethereum
researchers
to
rename
these
terms.
I
guess
for
two
reasons:
one.
B
I
think
it's
because
they're
really
interested
in
keeping
ethereum
unified,
so
they're
not
quite
sure
what
ethereum
one
plus
ethereum
two
equals
three
or
twenty
one,
and
also
I
guess
these
s1
and
s2
terms
aren't
very
descriptive
in
themselves.
You
can't
just
look
at
f2
and
know
what
it's
talking
about,
so
the
idea
was
to
rename
them,
s2
becomes
consensus,
f1
comes
execution
and
so
consensus
plus
execution
equals
ethereum.
B
This
is
the
general
idea,
so
I
use
the
new
terminology
I
kind
of
like
it,
because
it's
a
bit
more
descriptive
and
it's
also
what
the
specification
uses.
So
it's
easy
for
me
if
I
align
with
it,
but
I'm
not
going
to
judge
you,
you
know
you
do
you
call
it
whatever
you
like,
so
a
little
bit
more
terminology.
B
So
this
is
the
chain
that
I
showed
you
before
the
the
chain
of
the
chain.
So
I
had
these
were
blocks
that
they
had
staking
stuff
inside
the
blocks
and
then
transaction
stuff.
So
what
I'm
going
to
do?
I'm
going
to
rename
these?
I
didn't
rename
them,
but
at
least
to
decide
I'm
going
to
I'm
going
to
start
using
their
real
names,
so
the
transaction
stuff
inside
the
blocks
is
called
execution
payloads
and
the
actual
blocks
themselves
are
called
beacon
blocks.
B
So
what
we
end
up
after
renaming,
that
is,
we
have
these
beacon
blocks,
which
is
a
big
encapsulating
block
and
then
a
subsection
inside
those
beacon
blocks
is
an
execution
payload.
So
the
execution
payload
contains
all
the
stuff
about
transactions,
smart
contracts,
existing
ethereum
blocks
and
the
beacon
block
wraps
that
and
also
includes
information
about
proof
of
stake
validated.
B
So
just
quickly
for
the
I
guess,
programmers
and
developers
out
there
have
a
quick
look
at
the
data
structures.
So
this
is
a
beacon
block
body,
so
the
body,
the
meaty
part
of
the
beacon
block
we
can
see
the
first,
I
think
nine
fields-
these
are
all
proof-of-stake
things
and
then
finally,
the
bottom
one,
the
execution
payload,
which
is
new
in
the
merge.
This
is
where
we
put
all
of
the
execution
things.
B
So
if
we
have
a
look
at
the
definition
of
an
execution
payload,
it
looks
very
very
much
like
an
existing
ethereum
block.
So
if
you
were
to
go
on
episcon
start
clicking
around
on
the
block,
you'd
see
you'd
see
these
fields,
notably
proof
of
work.
Stuff
is
missing.
So
what
we've
done
here
is
we've
basically
taken
the
data
structure
that
is
a
ethereum
block
with
all
its
transactions
and
guest
limits,
gas
used
and
then
we've
put
it
inside
a
beacon
block
as
a
field,
so
we've
encapsulated
inside
the
other
one.
B
A
One
comment:
the
representation
of
ethereum,
both
layered,
the
consensus
layer
and
the
execution
layer
is
wonderful.
This
is
something
I
think
that
has
been
missing
for
a
very
long
time.
People
are
trying
to
understand
what
is
east
one
e2,
and
will
there
be
an
e3?
So
thank
you
for
that.
Visual
presentation.
B
No
worries
that
it
helps
very
good
alrighty,
there's
nothing
else,
I'm
going
to
jump
into
the
next
section,
it's
fairly
technical
as
well,
then
we'll
have
another
little
intermission
and
then
we'll
do
some
more
kind
of
less
technical
stuff.
Looking
at
coordination
all
right,
so
I
think
understanding
the
relationship
between
the
consensus
and
execution
layer
can
be
can
be
highlighted
by
looking
at
producing
and
processing
a
block.
So
I'm
going
to
walk
through
those
two
stages.
Now
so
first
we're
going
to
look
at
what
it's
like
to
produce
a
beacon
block.
B
So,
let's
start
with
our
bit
of
our
setup
here,
so
we
have
a
person
they're
on
their
computer.
They
happen
to
be
running
validator
number
42.,
so
inside
their
computer,
which
is
the
the
dotted
box
here,
they're
running
two
programs,
so
the
execution,
client
and
the
consensus
client.
Now
this
is
necessary
for
any
validator.
They
must
run
both
of
these
processes
and
those
processes
are
connected
to
each
other
via
an
api
json
rpc
that
the
execution
client
already
uses.
So
this
is
their
computer
they're
running
two
programs.
Those
programs
are
talking
to
each
other.
B
Those
programs
are
also
pointed
at
the
internet,
so
we're
producing
a
block,
and
the
first
step
in
that
is
that
the
consensus
client
learns
that
it's
been
elected
to
produce
the
next
block.
So
it's
the
consensus,
client
that
learns
this,
because
it's
the
one
that's
in
charge
of
validators
and
block
proposing
schedules,
and
things
like
this
so
first
thing
it
does.
Is
it
sends
a
message
to
the
execution,
client
and
it
says
please
prepare
to
produce
a
block,
and
it
does
this
via
the
engine.
Full
choice
updated
method.
B
So
it
sends
this
message
to
the
execution
client.
Then
the
consensus
client
doesn't
really
have
a
whole
lot
to
do.
At
this
point,
however,
the
execution
client
is
starting
its
algorithm
to
find
the
best
most
profitable,
most
efficient
set
of
transactions
to
include
in
that
block.
So
this
kind
of
mirrors
what
happens
to
proof
of
work
now
once
the
execution
client,
if
it's
mining
once
it
receives
a
block,
then
it
knows
it
has
to
try
and
build
a
good
set
of
transactions
on
top
of
that
block.
B
So
what
it's
trying
to
do
now
is
just
taking
its
time
to
collect
and
build
a
really
profitable
set
of
transactions.
So
the
next
step
is
that
the
expenses
client
its
slot
arrives
and
it
needs
to
choose
to
block.
So
it
knows
times
reduce
my
block,
it's
very
excited
because
it's
going
to
get
some
rewards
from
that
block
and
get
his
graffiti
in
the
chain.
B
So
what
it
does
is
it
sends
a
message
to
the
execution,
client
and
says:
please
send
me
that
execution
payload
that
you've
been
working
on
the
one
I
told
you
about
before,
so
it
uses
the
engine
get
payload
method
to
do
that.
So
then,
at
that
point
the
execution,
client
materializes
this
execution
payload,
which
is
just
like
a
current
ethereum
block
set
of
transactions,
the
state
route.
B
It
sends
that
back
to
the
consensus
client.
So
at
that
point
the
consensus
client
has
this
full
complete
beacon
block
with
execution
payload
in
it,
and
the
execution
client
can
kind
of
relax
for
a
little
bit
now.
So
the
consensus
client
will
then
broadcast
this
entire
block
to
the
whole
world.
So
all
the
other
beacon
nodes
ask
them
to
include
it
in
their
chain.
B
Hopefully
it
reaches
all
of
them
and
then
what
it'll
do
is
it'll.
Send
a
message
back
to
the
execution
client
saying
that
that
payload,
that
you
gave
me
a
validator
included
in
a
block
and
signed
across
it,
and
then
in
fact,
that
block
became
the
head
of
the
chain
and
it
uses
the
engine.
Fork
choice,
updated
method
to
do
that.
B
So
it
doesn't
just
tell
the
excuse,
client
that,
because
you
know
so,
it's
excited
to
you
know,
produce
a
block
and
it
can
put
a
picture
of
it
on
the
fridge
it
does
it
because
the
execution
client
relies
upon
the
consensus
client
to
tell
it
what
the
head
of
the
chain
is
and
which
blocks
are
valid
from
proof-of-stake
perspective.
So
just
because
the
execution
client
produced
a
valid
execution
payload,
it
doesn't
actually
know
that
a
proof-of-stake
validator
selected
that
payload
and
included
in
the
chain.
B
So
once
the
consensus
client
tells
the
execution
client
that
this
block
is
valid.
It's
the
head
of
the
chain
and
the
execution
client
can
perhaps
prune
some
old
blocks
that
it
didn't.
Doesn't
need
any
more
that
have
been
reverted
due
to
finality
and
it
can
impact
persists
that
that
new
expectation
is
powered
on
its
disk
as
a
canonical
payload.
B
So
but
before
we
move
on,
what
I
want
to
do
is
just
quickly
run
through
this
again,
just
quickly
just
to
try
and
cement
it
in
case
anybody
missed
anything.
So
we
have
our
setup.
Nothing's
happened
yet
accessories
client
learns
trying
to
produce
a
new
block,
so
it
sends
a
message
to
the
execution.
Client.
Please
prepare
to
produce
a
new
block.
So
then
extensive
client
can
chill
the
execution
client
is
working
to
produce
the
block.
Now
it's
time
to
produce
a
block.
B
B
So
what
have
we
learned
from
this
little
walkthrough?
First
thing
we've
learned
is
that
validators
must
run
an
execution
layer,
client
and
a
consensus
layer
client
in
order
to
produce
blocks.
This
is
definitely
not
the
case
on
existing
ethereum
for
miners.
They
didn't
even
have
to
touch
a
consensus
client,
so
anyone
that's
producing
blocks
for
ethereum
is
going
to
be
needing
to
run
both
of
these
things.
B
B
We
always
presented
it
as
a
hard
requirement,
but
it
wasn't
necessarily
so
now,
if
you're
a
beacon
chain
validator,
you
absolutely
cannot
produce
a
block
unless
you
have
a
consensus,
client
an
execution
client
connected
to
you.
So
these
two
services
are
connected
by
some
sort
of
rpc
api,
for
example
the
http
json
rpc
that
most
of
us
use
to
talk
with
guests
and
other
execution
clients
already.
B
B
Do
anything
like
that,
so
they're
completely
reliant
and
on
the
other
side
the
execution
client
relies
upon
the
consensus
client
to
know
which
chain
is
canonical,
so
the
execution
client
just
doesn't
have
any
of
the
proof-of-stake
machinery
in
it
to
know
who
is
a
validator
what
they
find
and
what
the
head
of
the
chain
is.
So
a
couple
of
lessons
we've
learnt
with
that
one,
so
I'm
going
to
go
through
to
processing
a
block
now
so
we're
going
to
look
at,
I
guess
the
other
side,
so
we've
we've
produced
and
published
a
block.
B
So
this
setup
we
have
a
generic
user
here
they
might
be
a
staker.
They
might
just
be
following
the
chain
just
for
the
fun
of
it
for
information
gathering
purposes
it
doesn't
matter,
their
setup
is
going
to
be
the
same.
They
have
you
know
inside
their
box
here,
they're
running
a
consensus
flight
and
an
execution
client.
So
one
thing
we
know
now
is
that
not
only
do
validators
have
to
run
of
these
processes,
but
anyone
following
the
chain
has
to
run
both
of
these
processes
connected
to
each
other.
B
So,
let's
start
through
the
example
for
this
one,
so
the
consensus,
client
from
the
network
it
received
this
speaking
block.
It
doesn't
know
whether
the
execution
payload
is
valid.
It
also
doesn't
know
whether
the
beacon
node
is
valid.
So
the
first
thing
it
does
kind
of
a
minor
step
is:
it
does
very
brief
validation
of
some
parameters
of
the
block
and
then
re-propagates
that
block
on
the
on
the
network
where
it
appears
so
they
can
start
processing
this
block.
B
So
after
it's
done
that
it
still
doesn't
know
detailed
validity
information
about
it.
So
what
it's
going
to
do
now
is
it's
going
to
send
a
message
to
the
execution,
client
and
say:
hey,
I
got
this
block,
and
can
you
please
verify
this
execution
payload
here?
So
it's
going
to
use
the
engine,
execute
payload
method
to
do
that.
So
after
that
we've
now
got
both
the
execution.
Client
has
its
payload
to
verify,
and
the
consensus
client
has,
if
beacon,
blocks
the
consensus
properties
to
verify
now
so
do
a
bit
of
work
eventually.
B
The
execution
client
in
this
example
determines
that
this
execution
payload
is
valid
and
it's
going
to
send
that
back
to
the
consensus
client,
who
now
knows
that
it
has
an
execution
payload
that
is
valid
and
it
could
continue
validation.
So
in
this
example,
the
consensus
client
says:
yep,
okay,
that
execution
payload
was
valid
and
all
of
the
consensus
properties
of
that
block
were
valid.
B
So
I'm
just
going
to
save
that
to
disk
now
persist
it
in
my
canonical
chain,
because
that
is
indeed
a
valid
block,
and
then
I'm
going
to
send
a
message
back
again
to
the
execution,
client
and
say
hey
that
payload,
that
I
got
you
to
verify
before
it's
now
at
the
head
of
the
chain
and
it
uses
that
engine
for
choice
updated
method
to
do
it.
So,
looking
at
this
again,
we've
all
we've
got
this
two-step
process.
B
Again,
where
we
say
hey
execution
client
is
this
payload
valid,
and
then
it
says
yes,
it
was
and
then
that
wasn't
enough
for
the
execution
client.
What
it
also
needs
to
know
from
us
is
okay.
That
was
that
payload
was
valid,
so
I
could
continue
to
verify
the
block
and
it
turned
out.
The
whole
block
was
valid.
I
thought
for
state
validator
to
approve
that.
So
there
you
go
it's
now
canonical
and
you
can
include
it
in
your
chain
and
deal
with
finality
and
stuff
like
this.
B
So
we
need
this
two-step
kind
of
phase,
but
remembering
that,
just
because
the
payload
is
valid
doesn't
mean
that
that
the
beacon
block
containing
it
was
valid.
So
before
we
move
on
I'll,
just
do
a
quick
recap
of
this
one
again,
so
I
have
an
empty
setup
again.
What
happens
is
the
beacon
block
comes
in
from
the
network?
We
don't
know
if
it's
valid,
just
some
brief
validation
on
it,
and
then
we
re-propagate
it
to
the
rest
of
the
network.
So
everyone
can
see
it.
B
Then
the
consensus
client
sends
their
payload
to
the
execution
client
for
verification.
They
both
are
then
ready
to
verify
some
components
of
the
block
in
parallel.
Then,
the
execution
client
sends
back
this
payload
to
the
consensus
client.
So
then,
the
consensus
client
can
then
complete
verification
of
the
block,
save
that
to
disk
assist
it,
and
then
the
execution
appliance
through
the
census
client
sends
a
message
to
the
execution
client
saying:
hey
that
was
valid.
You
know
update
your
fourth
choice.
This
is
the
this
is
the
truth
of
the
chain.
B
B
You
want
to
do
data
analytics
you're
going
to
have
to
run
both
of
those
because
independently
they
just
don't
have
the
smarts
to
verify
the
ethereum
chain
anymore,
and
I
repeat
this
a
couple
of
times,
but
the
execution
client
needs
this
second
message
to
verify
that
the
execution
payload
was
accepted
by
consensus.
So
you
know
just
because
we
found
a
valid
set
of
transactions
in
a
state
route
doesn't
mean
that
they
were
produced
by
a
ballot
validator.
So
I'm
just
keeping
this
in
mind.
It's
two-step
process.
D
And
then,
when
we're
looking
at
kind
of
the
consensus,
very
verifications,
that's
kind
of
more
well,
I
mean,
I
guess,
also
an
execution
and
on
consensus
layer.
The
there's
also
verification
of
the
headers,
just
to
make
sure
that
the
hashes
match
up
properly
and
things
like
that,
like
all
the
other
parameters,
are
correct.
D
D
A
So
I
have
a
question
here
you
mentioned
about:
if
someone
wants
to
run
an
explorer
or
they
might
have
to
run
both
the
things,
because
it's
a
two-step
process
right
how
good
or
valid
it
is
for
a
simple
user.
Do
they
have
to
do
that?
The
same
thing
like
if
there
is
someone
while
trying
to
be
a
validator
does
he
have
to
have
both
the
notes
or
he
can
use
some
third-party
services
there.
B
They'll
have
to
run
both
of
those.
It
might
be
that
that
people
come
along.
So
there's
like
ethereum
docker.
I
forget
what
it's
called:
there's
a
bunch
of
people
that
have
made
these
docker
kind
of
rappers
around
the
theory
like
beacon,
no
clients
and
and
the
and
the
current
ethereum
clients.
So
I
think
that
people
might
build
wrappers
around
it
so
that
the
presents
as
one
like
these
two
processors
present
as
one
thing
that
you
can
use.
B
Okay,
I
just
remembered
now
that
I
do
have
more
technical
stuff.
I
move
this
into
mission
forward,
so
there
is
a
little
bit
more
technical
stuff
and
then
we'll
we'll
go
into
the
organization
stuff,
so
ready
to
move
on
all
right.
Let's
move
on
okay!
So
let's
look
at
the
merge
from
an
infrastructure
infrastructure
perspective.
So
if
you're
someone
that
is
running
nodes,
what's
your
infrastructure
going
to
look
like,
so
in
the
previous
examples
we
showed
roughly
this
setup,
so
you've
got
consensus,
client
talking
to
the
execution
client
via
a
json
rpc.
B
B
This
scenario
is
also
very
possible,
so
you've
got
your
consensus
client
on
one
computer
on
one
side
of
the
world
and
you've
got
your
execution
client,
perhaps
on
a
server
on
the
other
side
of
the
world
and
they're
connected,
probably
by
http
over
the
internet,
and
they
can
talk
to
each
other.
Like
that,
you
want
to
make
sure
they've
got
a
secure
connection,
but
these
these
two
programs
can
be
located
anywhere
long
as
they
can
speak
to
each
other.
B
B
There
is
a
bit
of
an
edge
case
where,
if
one
of
these
execution
nodes
says
that
the
payload
is
valid,
that
the
other
one
says
it's
invalid,
but
that
would
be
a
basically
a
consensus
value
between
execution
nodes,
so
that
would
be
maybe
something
the
consensus
client
has
to
handle,
but
it
would
be
a
failure
mode,
so
this
kind
of
layer
is
possible
lighthouse.
Now
the
merge
version
supports
this.
You
can
connect
your
consensus
line
up
to
multiple
execution
clients.
B
B
So
the
other
side
of
that
is
a
many
to
one
relationship
of
many
consensus:
nodes
driving
the
one
execution
client.
So
this
is
not
something
that
is
currently
supported.
It's
not,
I
guess,
fundamentally
impossible.
However,
the
current
version
of
specification
isn't
written
to
really
tolerate
this
very
well,
and
the
reason
for
that
is
because,
because
the
consensus
node
is
telling
the
execution
client
what
the
head
of
the
chain
is,
it's
telling
it
what
the
shape
of
the
chain
looks
like
this.
B
It's
actually
a
subjective
view
of
the
network.
What
the
current
head
of
the
chain
is,
so
it
can
be
the
case
that
these
three
consensus
player
nodes
are
all
performing
perfectly,
but
due
to
some
geographic
network
difference,
they
might
actually
have
different
views
of
the
chain
and
the
the
execution
clients
presently
aren't
really
designed
to
handle
the
idea
of
it
having
being
bounced
around
between
views
of
the
network.
It
prefers
to
have
just
one
view,
so
this
layout
for
now
not
recommended,
maybe
we'll
get
there.
B
I
like
to
think
we
will,
but
I
wouldn't
go
down
that
path
at
this
point,
so
that
brings
us
to
trust
the
relationship
between
these
two
nodes.
So
you
really
need
to
trust
both
of
these
nodes.
So
if
you're,
a
validator,
you're
running
an
execution
and
consensus
client
you
need
to
be.
You
need
to
trust
both
of
those.
You
can't
just
trust
one
of
them
like
a
consensus,
player
node
for
instance.
B
B
So,
on
the
other
hand,
if
you
have
a
malicious
consensus
layer
node
in
your
system,
it
can,
among
other
things,
sensor
transactions,
so
it
can
just
simply
choose
to
not
show
you
certain
blocks
if
it
doesn't
want
you
to,
and
it
can
go
and
put
you
in
a
minority
chain.
So
you
need
to
you
need
to
be
in
charge
and
and
trusting
both
of
these
notes.
In
this
scenario,.
B
So
now,
looking
at
this,
I
guess
from
a
firewalling
perspective.
So
if
you're
going
to
run
these
processors
on
your
server
and
you're
wondering
how
you
configure
your
your
firewall,
then
it's
just
like
this.
So
you
you
have
a
there's,
a
client,
an
execution
client
running
on
the
same
server
and
then
outgoing
from
these
talking
to
the
you
know
the
big
dumpster
fire
that
is
the
internet.
B
These
days,
you
have
just
the
exact
same
ports
that
you
would
use
to
extend
the
client
and
the
execution
client,
so
you've
got
discovery,
ports
on
udp
and
then
I
guess,
like
you,
know,
rpc
communication
sports
on
tcp
for
both
extensive
client
and
the
execution
client.
So
the
firewall
on
that
side
looks
just
exactly
the
same
as
if
you
are
running
those
two
processes
independently
and
then
on
the
user
side.
B
We
have
the
rest
api
for
the
consensus
client,
so
it's
serving
a
json
http
api
over
tcp,
probably
and
then
for
the
execution
client.
We
have
json
rpc.
So
it's
using
the
current
ethereum
json
rpc
protocols,
http
websockets,
unique
sockets,
whatever
so
yeah
from
a
network
perspective.
It
just
looks
exactly
the
same
as
if
we
were
running
those
two
processes
separately.
Currently
then
goes
for
the
file
system,
so
they're
going
to
be
completely
separate
processes
on
the
file
system.
B
So
that
kind
of
covers-
I
guess
hopefully
what
it
looks
like
from
a
network
and
file
system
perspective.
The
moral
of
the
story
is
basically
they're,
just
completely
separate
processes
and
they
run
separately.
I
only
talk
to
each
other
by
that
ipc,
so
the
next
topic
I
want
to
talk
about
is
thinking.
So
anyone
that's
kind
of
run,
ethereum
nodes
knows
that
thinking
is
kind
of
the
first
thing
you
do.
It
takes
a
while.
Anyone
that's
worked
on
developing
knows
that
this
is
a
very
complicated
spot,
a
great
spot
for
optimization.
B
So
you
know
gas
and
aragon.
All
these.
All
these
implementations
have
worked
for
a
long
time
to
improve
their
thinking
protocol.
So
let's
have
a
little
bit
of
look
about
what
we
can
do.
So
we
looked
at
that
block
processing
workflow
before
and
then,
if
you
kind
of
think
about
you
know
seeking
an
existing
chain
from
genesis,
then
this
kind
of
naive,
lock,
step.
Sync
is
probably
the
first
thing
that
you
can
think
would
happen
so
kind
of
the
first
natural
thinking
idea.
B
This
is
what
we
did
in
the
first
test
step.
So
the
idea
is,
we
get
a
block,
consensus,
client
verifies
it
excuse,
the
client
verifies
it
and
we
can
move
on.
We
get
another
block,
you
know
they
both
verify
it
get
another
block,
they
all
get
certified.
So
at
this
step
we
are
basically
just
you
know.
Every.
D
B
Get
a
block,
we
make
sure
that
everyone
agrees
on
it
and
then
we
move
on.
So
this
works
really
well
when
everything
works
well,
but
we
have
to
consider
what
happens
if
there's
a
petition
say
something
it's
like
a
network
outage
between
the
cancer
player
and
execution
layer
client.
So
we
had
this
scenario,
you
know
block
zero
comes
in,
we
can
verify
it's
great
block.
B
One
comes
in
and
then
we
have,
you
know
something
bad
happens
at
the
storm
and
then
for
some
reason
we
can't
get
blocks
here,
block
one
verified
by
the
execution
client.
So
then
block
two
comes
along
to
the
consensus.
Client.
It
says:
yeah,
you
know
that's
great,
and
then
we
asked
the
execution
client
and
it
says
you
know
I
don't
know.
I
can't
verify
that.
I
can't
it
can't
possibly
verify
an
execution
payload
without
having
the
parent
and
we
didn't
give
the
parent
to
it.
B
So
what
we'd
have
to
do
in
this
scenario
is
figure
out
a
set
of
messages
for
the
execution
client
to
say:
hey,
you
know,
I
don't
I
don't
have
the
parent
and
then
we
go
okay,
which,
how
far
back
does
it
go,
that
you
don't
have
the
parent
and
then
we
will
give
it
the
blocks.
Then
it
catches
up
and
then
we
can
give
it
the
same
block
again.
So
that's
kind
of
the
lock
step
sink
here.
B
So
this
process,
the
consensus
layer,
basically
spoon
feeds
blocks
to
the
execution
layer,
let's
get
into
it
one
by
one
when
we
know
that
it
wants
them.
This
is
very
simple
to
reason
about
it's
also
quite
safe.
However,
the
recovery
from
petition
between
those
two,
I
guess
natively
it
could
be
desired,
we're
not
really
clear
about
what
it
could
be,
might
get
a
little
bit
complicated
and
then
compatible
with
sophisticated
think
algorithms,
so
something
you
got
to
consider
as
well.
Like
I
said
all
these
execution
clients
have
been
developing
these
fancy.
B
You
know
snap
and
warp
sync
methods
for
quite
a
while
and
they've
managed
to
massively
improve
the
sync
speed
of
current
ethereum,
and
they
do
that
by
not
just
by
downloading
blocks
faster,
but
by
sending
bits
of
the
state
across
the
network.
So
it's
complicated
themes,
schemes.
They
are
very
much
built
around
the
idea
of
how
things
work
with
proof
of
work.
So
you
kind
of
start
your
execution
client,
you
start,
and
you
might
be
at
the
earliest
block.
B
Given
how
far
we've
come
with
it
now
so
during
the
I
guess,
over
the
last
month
or
so,
we've
figured
out
that
we
probably
need
to
do
this
thing
called
an
optimistic
sync,
so
that
we
can
support
these
really
nice
existing
sync
mechanisms
for
the
execution
client.
So
the
idea
with
this
optimistic
thing
is
that
we
get
the
block
consensus.
Layer,
client
tries
verifies
it.
It
goes
and
talks
to
the
execution
client.
Maybe
it
verifies
it.
Maybe
it
can't
doesn't
know
in
this
example,
we'll
say:
pastor
just
couldn't
reach
his
execution.
B
Client
wasn't
synced.
So
we
don't
let
that
stop
us.
We
go
ahead
and
we
get
the
next
block
and
we
import
that
still
don't
know
we
just
keep
going
and
then
just
we
don't
know,
keep
importing
blocks
and
then
eventually
execution
client
figures
out.
It
can
sync
figures
out
the
span
and
then
it
comes
back
and
then
starts
approving
these
blocks
after
the
fact.
So
we
end
up
with
from
the
beacon
from
the
consensus
client
perspective,
it's
optimistically
thinking,
hoping
that
the
execution
layer
keeps
up
and
marks
them
as
valid.
B
So
in
its
optimistic
think.
We
now
assume
that
the
execution
node
has
by
its
own
pdp
network
can
actually
get
blocks
and
fits
a
state
from
its
other
peers
and
then
sync
to
things
so.
The
consensus
client
just
tells
it
what
the
latest
blocks
are
and
then
it's
up
to
it
to
get
that
state
and
get
to
a
state
where
you
can
start
verifying
blocks
for
the
head
of
the
chain.
So
this
becomes
a
little
bit
less
simple
for
reasons
I'll
go
into.
B
B
They
can
be
filled
in
and
it's
also
compatible
with
all
these
sophisticated
sync
algorithms
that
guest
and
other
clients
are
using
now
to
have
some
really
nice
properties
in
that
perspective,
so
we
want
to
look
at
how
to
make
optimistic,
think
safe,
then
we'll
say
we're
only
going
to
build
blocks
on
fully
verified
blocks,
so
we're
only
going
to
when
we're
making
a
new
block.
We're
not
going
to
build
this
up
a
block.
B
If
we
don't
really
know
whether
the
parent
is
valid
or
not,
it's
probably
possible
in
some
ways
it's
impossible
to
do
that,
but
we
just
have
to
maintain
this.
This
idea
that
we
only
build
the
top
fully
verified
blocks,
because
what
we
really
don't
want
to
do
is
to
be
contained
to
keep
building
blocks
where
it
doesn't
know
the
validity
of
the
execution
payload
and
then
finalize
the
invalid
execution
payload.
It
could
be.
You
know
a
double
spend
or
something
like
that.
That'd
be
really
disastrous.
B
B
So
that's
how
we
stay
safe
in
this
scenario.
So
let's
look
at
a
little
example,
so
here
we
have
a
chain
of
blocks,
so
the
earliest
block
so
say
the
genesis
block
is
on
the
left
here.
So
we
have
that
block
and
then
it
has
a
child
of
it.
It
points
back
to
it
by
a
parent
root,
and
then
we
have
a
fork
in
the
chain.
So
we
now
have
one
chain
up
the
top
with
three
blocks
and
we
have
another
chain
down
the
bottom,
with
two
blocks.
B
So
in
this
scenario,
the
chain
at
the
bottom
has
two
descendants
and
they're
both
fully
verified
and
then
the
chain
at
the
top.
It
has
one
descendant
it's
fully
verified
and
then
we've
got
these
two
blocks
here,
where
we
don't
actually
know
the
status
of
their
execution
payload,
so
this
chain
at
the
top
is
optimistically
verified.
B
So
it's
completely
valid
for
us
to
build
blocks
at
this
point,
however,
is
not
valid
for
us
to
build
blocks
here.
We
probably
shouldn't
be
able
to
build
blocks
there
just
from
because
if
we
don't
know
what
the
payload
is,
we
can't
produce
a
valid
successor
to
it,
but
for
terms
of
safety,
even
if
we
figure
out
how
we
could
do
that,
we
shouldn't
do
it
because
it's
unsafe,
so
in
terms
of
the
testing,
the
testing
is
voting.
What
validators
do
they
vote
for?
B
What
they
think
the
head
of
the
chain
is
so
they
could
attest
to
that
block,
but
they
shouldn't
attest
to
any
of
its
descendants
because
they
don't
actually
know
whether
it
is
valid
chain
or
not,
and
then
they
could,
if
they
wanted
to
a
test
down
here,
it'd
be
their
fourth
trace
algorithm
that
tells
them
where
to
test.
But
what
we're
trying
to
show
here
is
that
you
need
to
yeah.
You
can
only
test
the
blocks
that
are
fully
verified.
B
B
One
is:
should
we
allow
a
testing
or
block
production
if
there
are
any
optimistically
verified
blocks,
so
that
question
is
should
if
a
node
knows
that
it
has
incomplete
information
about
the
chain
should
didn't
be
building
blocks
at
all
because
it
might,
it
might
just
start
building
blocks
off.
You
know
very
old
things
start
creating
forks,
causing
a
lot
of
load
on
the
network.
When
it
knows
it
doesn't
have
a
complete
review.
So
maybe
should
it
just
at
that
point
say
yeah.
You
know,
look,
I
don't.
B
I
don't
know
enough
to
make
a
a
valid,
have
a
valid
opinion
here,
so
I'll
just
I'll.
Just
leave
that
be
that's
one
of
the
questions
that
we
haven't
quite
come
to
an
agreement
on
yet
and
another
one
is,
I
guess,
use
a
thing
of
should
we
serve
those
optimistically
verify
blocks
by
the
api?
So
presently,
if
we,
if
we're
serving
blocks
of
the
api,
we
have
this
implicit
agreement
to
the
user
that
they're
valid
and
they
can
probably
action.
B
You
know
what
whatever
is
in
that,
but
if
the
block
is
not
fully
verified,
do
we
really
want
to
be
telling
the
user
about
it?
So
the
I
guess
the
black
and
white
would
be.
Do
we
tell
them
or
do
we
not
and
then
in
between
would
be?
Maybe
do
we
add
a
flag
to
tell
them
whether
it's
optimistically
verified
or
not?
So
these
are
some
of
the
open
questions.
They're
not
they're,
not
show
stoppers
they're,
just
the
things
we're
discussing
so
at
the
moment.
B
The
discussion
about
optimistic
think
is
on
a
lighthouse
issue
that
I
started
just
to
chat
internally
with
the
team,
but
it
got
a
bit
broader.
So
I
think
that's
where
the
most
of
this
discussion
on
optimistic
thinkers
happened
at
the
moment.
Maybe
we
eventually
get
moved
to
a
different
repo
or
something
but
yeah.
If
you
want
to
check
it
out
and
follow
on
jump
onto
that
lighthouse
issue
there
all
right
another
intermission.
So
this
I
promise
is
the
end
of
the
technical
stuff.
So
I'll.
A
I
have
couple
of
questions
so
two
questions.
I
think
one
is
related
to
optimistic
sync
when,
if
you
can
go
back
to
that
diagram,
so
here
in
this
diagram,
you
mentioned
that
the
attestation
should
be
done
to
the
last
valid
block
and
there
are
two
possibility
to
do
it.
So
would
there
be
any
algorithm
to
decide
which
one
will
be
accepted,
because
both
would
be
the
valid
at
the
station
here
right.
B
So
what
the
consensus
client
would
do
is
it
would
weigh
up
the
the
weight
of
the
votes
that,
for
previous
attestations,
it's
seen
and
then
vote
on
the
one
that
it
thinks
everyone
else
is
voting
on
and
if
it
hasn't
seen
anyone
else,
though
it
takes
kind
of
like
a
an
arbitrary
thing,
but
yeah
definitely
definitely
an
algorithm
to
to
choose
which
one
of
those
possible
targets
should
vote
on
and
that
that
algorithm
is
standardized
between
clients
and
tested
and
stuff.
Like
this.
A
B
I
think
it'll
say
so
it
it
was.
It's
been
used
since
genesis
very
important
part
of
the
beacon
chain,
and
I
don't
think
that,
apart
from
being
aware
of
this
optimistic
thing,
I
don't
think
it's
going
to
change
at
all
for
the
merge
there's
a
couple
of
little
changes.
You
want
to
make
to
fork
choice,
but
nothing,
that's
related
to
merge
so
yeah
that
algorithm
already
exists
already
in
production.
It
doesn't
need
any
changes
really
to
support
this.
A
B
Oh
yeah
sure
yeah,
so
the
idea
is
the
fork
choice.
Now.
Doesn't
it
just
has
blocks
and
they're
all
fully
verified?
If
they're
not
fully
verified
they're,
not
in
the
tree,
we
would
need
to
modify
it
to
support
partially
verified
blocks,
but
it
wouldn't
change
the
specification.
I
don't
think
it
would
just
change
the
implementation.
So
that's
something
I'm
going
to
do
in
the
next
couple
of
weeks
changed
our
implementations.
B
Well,
other
parts
of
the
consensus
client
need
to
know
about
the
unverified
tips
as
well,
because
what
it
wants
to
be
doing,
although
it's
not
a
testing
or
building
blocks
for
those
unverified
blocks,
it
should
be
trying
to
ask
its
peers
for
descendants
of
those
blocks.
So
consensus
client
has
to
have
this
idea
of
what
it
can
attest
what's
safe
and
then
what's
optimistic
in
terms
of
what
it
should
keep
building
on.
A
B
Yeah
we
can
expect
some
lags.
I
think
what
will
happen
is
so
that
execution
layer
can't
get
ahead
of
the
consensus
client
really
at
this
stage,
but
the
consensus
plan
can
definitely
get
ahead.
So
what
we
probably
see
is
the
we'll
probably
see
that
consensus
client
sync
fairly
quickly
to
the
head
and
then
have
to
spend
some
time
waiting
for
the
execution
node
to
catch
up,
because
the
executive
mode
is
actually
its
sync
is,
is
much
more
burdens
and
much
more
heavy
than
extensive
clients.
B
So
we'll
probably
see
you
know
it
catch
up.
Your
consensus
note
will
probably
say
I'm
at
the
head,
but
I'm
still
waiting
for
my
execution
layer
to
sync
up,
I'm
still
optimistically
think
and
it'll
catch
up
and
then
you'll
probably
get
a
notification
saying.
Okay,
you
know
both
of
your
clients
are
ready
to
go
and
you're
you're
good
to
go.
B
So
when
the
consensus
client,
we
can
think
of
voters
together,
so
we'll
just
say
that
if,
if
they're
not
both
synced,
then
you're
not
synced,
and
then
from
that
perspective
we
maintain
the
existing
guarantee.
So
if
someone
has
a
non-sync
execution
node,
they
they
wouldn't
trust
it
anyway.
I
guess
I
mean
that's
not
true.
B
They
could
trust
it
to
the
point
where
it's
up
to
so
we
do
bring
in
this
idea
that,
if
you're
the
beacon
node,
you
might
be
off
on
an
optimistic
branch,
that's
invalid
and
you
could
you
could
query
it
and
get
an
invalid
state,
but
yeah,
like
I
said,
as
long
as
as
long
as
we
mark
to
the
user,
we're
clear
to
the
user
that
an
optimistic
synced
block
is
not
a
real
block.
Then
then,
we're
safe
from
double
spend.
A
All
right,
that's
interesting,
so
I
have
just
one
last
question
about
the
communication
tool
you
mentioned
about
json,
rpc
and
rest
api.
I
was,
I
suppose
there
was
some
discussion
going
on
whether
the
execution
client
should
continue
with
json
rpc,
and
this
one
should
have
rest
api
or
should
have
the
common
one.
Is
there
any
decision
on
that
part
like
we'll
be
using
different
for
different
clients.
B
I
haven't
heard
on
that.
Actually
I
know
that
I
know
peter
from
guess
is
regrets
using
json
rpc
for
the
execution
client,
but
I'm
not
sure
I
also
haven't
been
following
this
because
I'm
in
a
bit
of
a
consensus
world
I
haven't
been
following
how
that's
been
going
to
change
it
to
rest?
My
understanding,
I
guess,
was
that
we're
pretty
far
down
that
path
it'd
be
hard
to
change
but
yeah
if
they're
open
to
change
I'm
open
to
it.
A
D
No
worries-
I
guess
I'm
at
a
similar
note
to
that
right
now
we
mentioned
that
the
communication
between
the
consensus
layer
and
the
execution
layer
is
itself,
I
believe,
json
rpc
correct.
Do
you
think
that
we'll
see
kind
of
like
two-in-one
clients,
or
is
that
actually
like,
is
specked
out
that
there
must
be
two
separate
clients
that
communicate
with
each
other.
B
Yeah
two
in
one
clients
is
a
great
question
actually,
so
I
think
I
mentioned
before
about
the
idea
of
wrapping
the
two
together
in
the
into
present
as
one
bundle.
So
that's
that's
not
really
your
question.
What
you're
asking
is
like
you
know,
because
it's
kind
of
one
process
it'll
do
both
I'm
not
sure
about
this.
D
B
Which
is
also
the
maclaurin
majority
cloud
on
that
side,
then
we're
kind
of
going
to
double
this
effect.
We
now
we're
just.
We
just
have
this
prism
guest
network,
so
this
is
the
kind
of
thing
I
guess
this
is
the
opposite
side
of
gluing
them
together
is
the
ability
to
have
a
diversity
there
between
the
two
so
yeah.
B
If
we
were
to
look
at
just
what
is
easier
for
users,
I
would
say
that
they're
probably
going
to
glue
each
other
together,
but
then,
if
we
look
at
the
drives
behind
client
diversity,
which
I
think
is
very
strong,
then
there's
going
to
be
incentives
for
clients
not
to
glue
each
other
together.
So
from
lighthouse
where
I
work,
we,
that
was
something
I
was
considering
earlier
was
going
together,
but
I
think
for
quite
diversity.
B
All
right,
so,
let's
get
out
of
the
technical
weeds
and
talk
a
little
bit
about
progress,
people
meeting
in
person,
fine
lines
and
stuff
like
that.
So
if
you
want
to
talk
about
progress
on
the
merge,
we
really
have
to
talk
about
the
amphora
workshop,
so
people
might
have
seen
this
happening
on
twitter.
So
just
to
be
clear,
I
only
participated
in
it
remotely.
I
really
wanted
to
be
there.
B
These
people
are
my
friends,
but
I
couldn't
because
I
mean
australia
and
our
borders
are
pretty
tight
at
the
moment
with
with
good
old
covid.
So
this
event
it's
called
m4.
It
was
in
greece.
It
was
a
face-to-face
event,
so
the
idea
was
to
get
you
know,
execution,
client
developers
and
researchers
other
people
as
well
into
the
same
physical
space.
B
So
they
can
sit
side
by
side
and
hack
together
on
test
nets.
They
can
get
to
know
each
other
and
also
kind
of
form,
some
relationships
that
we're
going
to
need
from
post-merge
ethereum,
so
execution,
ethereum
and
consensus.
Ethereum
has
been
separate
for
a
while,
and
it's
good
to
you
know
it's
good
to
be
able
to
put
a
name
for
some
github
handles
sometimes
really
helps
with
some
communication.
B
B
So
multi-client
now
comes
with
significant
complexity,
so
we
have
a
bit
of
an
m
squared
problem
here
for
programmers
out
there.
So
when
we
say
multi-client
that
means
that
lodestar
needs
to
be
able
to
talk
to
best.
We
know
the
mind
aragon
during
js
and
go
ethereum
and,
conversely,
so
we
have
all
these
nodes
linking
all
of
these
things.
We
need
to
test
all
of
these
different
compatibilities
between
between
these
clients,
so
that
was
one
of
the
challenges
of
the
workshop
and
also
of
ethereum.
B
We
had
some
milestones
with
this
event,
clearly
laid
out
by
danny
and
tim,
so
milestone.
Zero
was
basically
just
start
implementing
start
working
in
this
workshop.
Everyone
did
that
before
we
got
to
greece,
m1
was
we
all
implement,
implement
our
relative
specifications
and
then
we
get
the
test
vectors
passing
so
yeah.
So
m1
was
also
met
by
most
people
before
they
got
to
greece.
Just
irons
out
and
test
vectors
help
iron
out
any
obvious,
stupid
mistakes
that
we
make
milestone.
B
Two
was
a
one-to-one
interop
between
an
execution,
client
and
a
consensus.
Client,
so
that'd
be
safe,
lighthouse
and
guest
talking
together,
building
a
chain
together,
and
that
was
without
the
merge
transition.
So
with
blockchains
doing
upgrades
consensus
changes
complicated,
so
the
first
first
networks
we
did.
We
just
said:
let's
just
assume
that
the
merge
happens
at
genesis
and
we're
just
only
going
to
build,
merge
blocks
and
then
so
m3
is
the
same
client
layout.
You
guess
my
house
whatever,
but
then
we
do
go
through.
B
So
we
start
without
the
merge,
and
then
we
do
the
merge
forks
and
then
we
bring
in
the
terminal
block,
and
then
we
roll
like
this
so
once
we
all
figured
out
that
we
can
do
the
merge
transition
with
each
other.
So
it's
like
you
know
from
lighthouse
perspective,
we
do
m2
and
m3
with.
We
do
do
them
with
all
of
the
consensus.
Oh
sorry,
yes,
aragon,
that's
betsu
and
make
sure
that
we
can
do
the
build
chains
with
them
and
then
m4
is
kind
of
bring
a
few
more
people
into
the
mix.
B
B
B
B
So
he's
tweeting
saying
that
we
started
this
test
net
called
piss-off.
That
is
a
block
explorer.
If
you
want
to
go
that
link
just
type
https
in
front
of
it
and
then
there's
some
instructions
there
on
how
to
join
that
testnet.
The
instructions
he's
given
kind
of
for
devops
people
at
the
bottom.
I've,
given
this
link,
which
is
a
queen
cashew
guide,
which
shows
just
anyone
how
to
join
pithos.
B
So
there's
a
bunch
of
people
running
it
now
go
to
teams
handing
out
bugs
people
playing
with
it,
transferring
us
to
each
other
doing
transactions,
so
it
was
pretty
cool
the
the
the
tests
they
sort
of
the
event
did
did
achieve
what
it
set
out
to
achieve.
Then.
Also,
this
tweet
from
marius
from
the
guest
team
was
pretty
exciting
as
well,
so
he's
thanking
everyone
for
organizing
it
and
he
says
that
he
thinks
it
brought
them
at
least
three
months
closer
to
the
merch
in
just
one
week.
B
So
my
last
slide
here,
looking
at
the
engineering
standing
of
the
merge.
So
presently
we
have
this
public
multi-client
test
net
running
at
skypost.
I
was
talking
about
before
anyone
can
join
it.
You
only
have
one
major
client,
that's
not
yet
on
pistol,
it's
aragon,
I'm
sure
they
have
great
reason
for
it.
I
think
they're
busy
kind
of
spinning
up
their
client
and
they're
definitely
not
holding
up
anyone,
so
I
think
they
can
more
than
comfortable
to
take
their
time.
B
So
when
they're
ready
the
downstream
tooling
for
the
merge
stuff
is,
is
it's
still
a
bit
immature?
So
the
clients
are
pretty
much
ready
in
a
in
a
very
liberal
sense,
but
things
like
block
explorers,
for
instance.
So
we
have
so
the
beacon
chain
beacon,
with
a
dot
between
the
a
and
the
I
n
the
block
explorer.
They
have
great
execution
like
a
current
ethereum
explorer.
Then
they
also
have
a
great
consensus
explorer.
B
I
think
this
is
really
good
they've
kind
of
built
a
rough
kind
of
merge
together
of
the
two,
so
we
can
explore
pythons,
but
the
the
linking
between
the
two
isn't
isn't
super
glossy
and
I
think,
there's
a
lot
of
other
tooling
that
we
haven't
thought
about.
Yet
that
needs
to
develop.
So
that's
that's
completely
expected
that
you
know
the
clients
need
to
get
their
first
before
downstream.
Tooling
again,
so
that's
something
that
we
need
to
that
happens
before
we
can
look
at
merging
mainnet.
B
B
I
think
at
this
point
the
the
ethereum,
the
clients
are
pretty
close,
we're
not
quite
there
yet,
but
we're
quite
close,
but
I
think
that
something
we
probably
need
to
see
before
we
go
to
mainnet
is
seeing
long-lived
test
nets
running
for
perhaps
a
matter
of
months,
just
so
that
you
know
things
like
sf
scan.
You
know,
big
things
like
sushi
uni
swap
can
can
start
running
on
this
this
in
this
new
merge
environment
and
see
how
things
work
for
them.
B
Some
of
the
things
I
haven't
mentioned
here
are
there's
going
to
be
slight
changes
to
the
evm
in
terms
of
randomness
and
some
of
the
things
some
of
the
things
that
we
were
expecting
to
get
from
proof
of
work
has
changed
slightly,
so
we
do
need
to
make
some
some
very
hopefully
edge,
casey
breaking
things
on
on
in
smart
contracts,
so
yeah.
I
think
that
I
guess
in
terms
of
engineering
we're
pretty
close,
but
in
terms
of
the
community
getting
their
eyes
and
hands
on
this.
B
A
B
A
No,
no,
it
was
really
interesting.
So
I
have
one
question
on
the
emerge
test
net.
I
think
it's
related
to
m4a.
So,
first
of
all
I
would
agree
that
amphora,
the
merged
interrupt
event
in
greece
was
a
big
milestone
towards
this.
The
big
change
that
we
are
expecting
and
I
assume
that
a
lot
has
happened
in
this
covert
operation
with
multiple
combination
of
el
and
cl
clients
over
there.
So
what
is
the
interrupt
between
two
cl
clients
mean
here
like
I
was
looking
into
this.
A
B
Oh
yeah
good
question:
I
meant
to
mention
that
during
that
diagram,
what
well
done
you
picked
up
on
it
so
that
that
big,
I
guess
mesh
diagram
I
showed-
did
miss
out
the
interrupt
between
the
consensus
and
execution
clients
because
they
also
need
to
interrupt
with
each
other.
So
that
is
that's
kind
of
what
the
consensus
side
has
been
interrupting
with
each
other
since
before
mainnet
and
the
consensus
side
as
well.
B
So
this
is
just
basically
like
on
the
beacon
chain,
all
the
different
clients
interrupting
with
each
other
speaking
over
the
network,
sharing
blocks
and
then
also
the
same
things
the
execution
side.
So
it's
definitely
something
that
is
complicated,
but
it's
something
we've
been
doing
for
a
while
now.
B
So
it's
generally
a
little
bit
easier
for
us
interrupting
between
our
our
own
kind,
if
you
will,
rather
than
with
the
yeah
the
others,
so
that
yeah,
that
that
that
interrupt
means
between
say,
load,
star
and
lighthouse
means
they're
appearing
on
the
our
peer-to-peer
network
and
then
sending
blocks
verifying
them.
I'm
agreeing
on
the
on
the
roots
of
things,
the
hashes
of
things
and
yeah
generally
generally
being
kind
to
each
other.
In
that
way,.
A
Interesting,
I
have
one
more
question
on
the
post
that
you
shared
I'm
in
the
github
link
that
you
shared
about
optimistic
post,
mods.
Sync
in
that
piece
you
have
mentioned
at
one
place
like
there
are
some
uncertainties
that
clients
are
dealing
with.
I'm
just
trying
to
understand
what
is
the
proposed
way
forward
if
there
is
any.
D
B
Think
so
in
that
comment,
there's
some
talk
between.
I
think
danny
talks
a
bit
about
what
he
thinks
is
safe
and
unsafe
in
there.
I
think
we're
not
super
far
forward.
I
think
the
so
in
terms
of
building
should
we
build
blocks
atop.
So
there's
two
questions.
There's
one
is:
should
we
should
we
a
test
or
build
any
blocks?
If
we
have
any
uncertainty,
I
think
leaning
towards
safety.
There
probably
say
no,
but
it
is
kind
of
up
to
each
execution
client
to
determine
what
they
want
to
do
there.
B
So
it's
not
it's
not
necessarily
a
strict
requirement
protocol
that
we
have
to
decide
on.
We
kind
of
had
this
wiggle
room
for
people
to
go
their
own
way,
so
I
think
it
would
probably
be
in
terms
of
the
way
forward.
There
it'd
probably
be
something
like
determining
whether
all
the
clients
agree
that
we
should
just
take
the
simplest
method
and
if
they
do,
that
will
be
an
easy
solution.
B
If,
if
it
turns
out,
you
can
go
either
way
and
people
have
differing
views,
I
think
it
will
just
go
either
way
and
we
won't
all
agree
on
it,
and
that
would
be
totally
fine
as
well.
I
mean
that's
kind
of
that's
why
we
have
a
like
diversity
and
not
a
dictatorship,
so
that
we
can
experiment
with
different
things.
Then,
when
it
comes
to
the
api
one,
that
one
is,
I
think
so,
there's
kind
of
when
it
comes
to
decisions
in
the
client.
B
I
guess
a
group
of
like
very
close
to
the
client
developers
and
some
of
the
researchers
and
they
kind
of
get
they
just
kind
of
decide
on
those
things,
because
they're,
the
only
ones
that
are
interested
enough-
and
I
guess
informed
enough
to
make
decisions
about
them
and
then,
when
it
comes
to
the
api,
there's
a
bit
of
a
broader
circle
of
people
who
get
involved,
which
is
great
because
the
people
very
close
to
the
client.
You
know
we
don't
really
it's
hard
for
us
to
think
about
what
users
want.
We
just
think
about.
B
D
B
To
there
to
discuss
about
what
people
think
and
I
think
the
choice
is,
we
absolutely
can't
serve
optimistic
or
non-optimistic
blocks
as
the
same
thing.
It's
just
that's
just
completely
unsafe.
I
think
the
question
is
is:
do
we
serve
them
at
all
like
do
we?
Do
we
serve
them
with
a
flag
to
indicate
they're
safe
or
not,
or
do
we
just
simply
not
serve
them
at
all?
B
I
would
lean
towards
not
serving
them
to
all,
just
because
it's
the
safest
thing,
but
it
might
be
that
once
we
open
this
up
to
like
some
broader
participants
that
they
say
no,
you
know.
Actually
you
know
my
system.
That
optimistic
block
is
very
important
for
this
reason,
so
then
we'll
say:
okay,
well,
yeah!
You
know
good
point,
let's
open
it
up,
so
I
think
that's
kind
of
the
way
forward.
We
have
on
those
those
two
big
unanswered
questions.
A
Interesting
and
historically,
we
have
seen
eat
too
sorry,
the
wrong
term.
The
consensus
layer,
client
teams
are
really
good
in
like
coming
to
a
conclusion
real
soon,
maybe
discussing
it
async
and
in
some
of
the
consensus
layer
meeting
they
implement
this
meeting
that
goes
on
well,
I
know
that
there
is
a
lot
to
unpack
on
the
merge,
but
unfortunately,
it's
time
to
wrap
up
just
want
to
check,
but
the
panel,
if
you
have
any
other
final
question,
comment
or
thought.
B
Yeah,
well
I
mean
I
guess,
in
software
engineering,
especially
in
this
distributed
ethereum
stuff,
there's
always
uncertainty
about
the
time
zones
that
we,
the
time
frames,
that
we
won't
meet
them,
but
I
think
that
there
is
a
lot
of
pressure
coming
from
various
places,
one
from
the
ethereum
foundation,
research
team-
so
we
know
justin
drake,
for
instance,
is
applying
pressure
to
make
it
happen,
and
he
has.
He
has
a
lot
of
levers,
his
macgy,
so
he
can,
I
think,
he'll
be
a
driving
force
in
it.
B
We
also
have
to
be
concerned
about
giving
miners
too
long.
So
if
we
delay
this
for
too
long,
then
we
give
time,
for
you
know,
unhappiness
to
breed
and
you
know
strategies
to
counter
it
happen.
So
there
are
a
fair
few
things
pushing
us
towards
it
and
I
think
it's
achievable
so
that
gives
me
a
higher.
I
guess
degree
of
hope
is
going
to
happen
early
next
year.
A
D
Yeah
sure
thanks,
so
we
are
excited
to
announce
that,
due
to
the
success
of
the
people,
never
series
thus
far
we're
interested
in
expanding
the
initiative
a
little
bit
and
we're
looking
to
branch
off
into
a
podcast
spin
off.
Deepening
we're
looking
to
do
long
form,
technical
interviews
with
different
people
in
the
ecosystem
on
different
technical
topics,
not
necessarily
just
around
kind
of
the
infrastructure
and
eip
structure
that
served
people
so
well
and
so
keep
keep
posted.
We're
looking
to
try
and
start
that,
probably
within
the
next
coming
weeks.
A
Awesome,
thank
you,
william,
thanks
once
again
paul
to
talk
about
one
of
the
biggest
change
that
need
a
lot
of
development
coordination
and
a
lot
of
education.
I
hope
more
users
join
the
stakers
community,
the
ethereum
chain
and
help
contribute
to
the
ideal
ecosystem
that
we
are
looking
for
for
people
who
missed.
We
have
recorded
an
episode
on
eip
3675,
as
paul
mentioned
in
his
presentation
with
mikhail
kalanin.
The
recording
is
available
on
ech
youtube
and
we
are
also
trying
to
get
paritos
to
explain
about
the
pithas
devnet.
A
You
may
find
the
contact
of
the
guest
and
the
list
of
relevant
resources
in
the
description
box.
If
you
like
this
talk,
please
hit
like
and
share
it
with
the
community
subscribe
to
ethereumcategory's
youtube
channel
for
meeting
and
educational
resources
for
utm
blockchain,
we'll
be
back
with
another
interesting
topic.
For
you
till
then
keep
watching
keep
sharing
your
love
with
ethereal
cat
hoodies
see
you
soon
have
a
good
one.