►
Description
Topics covered
-----------------------------
0:55 - Client’s introduction
1:26 - Guest’s introduction
2:27 - Presentation
2:35 - About Go-ethereum
4:22 - Merge code
9:39- Merge testnet preparations
14:38 - Shadow forking
16:23 - Testnet Forking
20:29 - Client Releases
22:55 - Ropsten Merge Issues
27:44 - Other Testing - Fuzzing, Hive test, Kurtosis, Antithesis
28:17 - Interesting bugs
40:04 - Cool upcoming features - Reverse diff, Verkle trees, Danksharding, Light clients, Chain pruning, Shanghai, Withdrawals
47:40 - Q & A - What difference did fuzzing & testing made on testing the merge
51:04 - What is the main reason for the continued shadow fork? How many more shadow forking is expected?
53:50 - EL specific metrices that Geth or other client teams are taking care of
57:17 - Any special preparation for Goerli & Prater testnet as both are long running testnets
59:23 - Plug in - Shadow forking episode :)
59:53 - Best client combination
1:02:36 - Do you think Geth will be the majority client post merge?
1:05:27 - Journey towards the merge upgrade so far?
1:10:24 - Message for our listeners
Resources:
-----------------
Slides: https://docs.google.com/presentation/d/10Ox1kyDOyVARkYVkZ4WYgxAqeaHH0-5XYT-af-KwrfA/edit
Kiln - The Merge Testnet & Goreli shadow forking with Marius - https://youtu.be/3AkDPL0RWtk
EIP-3607: Reject transactions from senders with deployed code (Marius W & Andrew A.) - https://www.youtube.com/watch?v=wnRBsjDVQnI&list=PL4cwHXAawZxqu0PKKyMzG_3BJV_xZTi1F&index=28&t=2s
EIP-1474: Remote procedure call specification with Erik Marks & Marius VanDerWijden - https://www.youtube.com/watch?v=fxhXsg9g4nc&list=PL4cwHXAawZxqu0PKKyMzG_3BJV_xZTi1F&index=49&t=1s
KnowYourClient - https://www.youtube.com/playlist?list=PL4cwHXAawZxoruie1hmYWJfiakpYivXft
PEEPanEIP playlist - https://www.youtube.com/playlist?list=PL4cwHXAawZxqu0PKKyMzG_3BJV_xZTi1F
TheMerge playlist - https://www.youtube.com/playlist?list=PL4cwHXAawZxqoLxXqZqT4hcYhoHoP6w12
Check out upcoming EIPs in Peep an EIP series at https://github.com/ethereum-cat-herders/PM/projects/2
Follow at Twitter
-----------------------------------------------
MariusVanDerWijden @vdWijden | Pooja Ranjan @poojaranjan19
Contact Ethereum Cat Herders
---------------------------------------------------
Discord: https://discord.io/EthCatHerders
Twitter: https://twitter.com/EthCatHerders
Medium: https://medium.com/ethereum-cat-herders
GitHub: https://github.com/ethereum-cat-herders
Website: https://www.ethereumcatherders.com/
A
A
A
A
little
bit
about
the
client
go
ethereum
is
one
of
the
three
original
implementations
of
the
ethereum
protocol.
It
is
written
in,
go
and
is
fully
open.
Source
official
documentation
suggests
go.
Ethereum
supports
the
transition
of
ethereum
from
proof
of
work
to
proof
of
stake
and
will
be
available
as
an
execution
layer
post
merge.
We
will
get
to
learn
more
about
geth
or
go
ethereum
client
in
this
episode
with
marius,
but
first
maybe
have
a
brief
introduction
for
our
new
listeners.
B
B
Since
two
years
now
and
right
now,
I'm
focusing
on
shipping
the
merge
and
getting
test
cases
for
all
the
clients
and
hive
tests
and
fuzzing
and
like
lots
of
lots
of
different,
merge
related
stuff.
That
needs
to
be
done,
and
today
I'm
going
to
talk
about
our
implementation
and
some
interesting
things
that
we
encountered
along
the
way.
A
B
Yeah
today
we
people
neep.
We
look
at
the
go.
Ethereum
merge
implementation,
as
puja
already
said,
go
ethereum
is
one
of
the
original
clients
of
of
ethereum
and
right
now
it's
run
by
80
of
the
network.
This
is
bad.
If
you
can,
you
should
run
a
different
client
because
of
client
diversity,
but
we're
also
happy
to
have
you
guys
from
our
client.
Of
course,
the
go
ethereum
client
is
written
in
in
golang,
and
our
focus
is
specifically
the
ethereum
mainnet,
so
other
clients,
like
bisou
or
nethermind
or
aragon.
B
They
also
focus
on
other
test
nets.
Other
other
chains,
private
networks
and
but
go
ethereum
is
purely
focused
on
the
ethereum
and
we
support
some
of
the
other
algorithms.
Some
of
the
other
test
nets
only
for
ethereum
testing
basically
and
go
ethereum
is
the
only
original
client
that
is
able
to
go
through.
The
merge
on
mainnet
nethermine,
bisu
and
aragon
are
also
able
to
go
through
the
manual
transition,
but
they
joined
later
and
the
guest
team
is
part
of
the
ethereum
foundation.
B
Geth
was
started
when
ethereum
was
started
by
jeffrey,
jeffrey,
wilkers
and
right
now,
peter
zilagi.
Is
the
team
lead?
We
have
felix
also,
who
I
think
he
was
the
first
employee,
employee
of
jeff
and
martin
who's-
also
doing
the
security
stuff
on
eth1,
who
also
joined
kind
of
joined
the
guest
team
full
time
and
yeah.
So
I
want
to
talk
a
bit
about
the
merch
code,
where
you
can
find
it.
B
B
So
if
you're
an
avid
listener
of
people
nip,
you
already
know
this,
but
basically
after
the
merge
you
need
to
run
two
different
clients.
You
need
to
run
the
execution,
layer,
client,
guess
or
erigon,
and
you
need
to
run
a
consensus
layer,
client
like
prism
or
lighthouse
and
the
the
x,
the
consensus
layer
client
basically
tells
the
execution
layer
client
what
to
do,
and
for
that
we
use
the
engine
api
and
so,
for
example,
new
payload
tells
the
is
the
call
for
the
consensus
layer
to
tell
the
execution
layer
hey.
B
This
is
a
is
a
new
block.
Please
execute
this
block
and
tell
me
if
this
block
was
executed
correctly
and
yeah.
That's
that's,
as
I
said,
located
under
the
catalyst
package.
This
is
the
name.
Catalyst
was
historically
grown
because
guillaume
did
the
first
implementation
of
this
and
called
it
catalyst,
and
we
kind
of
still
have
the
name
for
the
package
and
the
consensus
engine
is
located
under
consensus.
Slash
speak
consensus.go.
B
This
implements
the
verification
rules,
basically
the
header
format
or
the
things
that
we
store
in
the
header
and
then
the
block
header.
They
change
a
bit
and
we
need
new
verification
rules.
We
need
to
verify
that
so
post
merge.
There
won't
be
any
uncles
in
the
block,
for
example,
and
so
we
need
to
verify
that
the
uncle
hash
is
always
set
to
the
zero
hash
and
blocks
post.
B
Merge
will
not
have
the
difficulty
set,
so
we
will
need
to
verify
that
the
difficulty
is
always
zero
for
these
headers
and
these
verification
rules
are
implemented
in
the
consensus
engine
and
then
we
have
biggest
change
is
in
the
sync,
I
think
the
well.
It's
might
not
be
like
line
wise,
the
biggest
change,
but
it's
complexity-wise.
It's
definitely
the
biggest
change
is
for
syncing,
so
for
retrieving
the
old
blocks
from
the
from
the
blockchain,
and
this
is
located
under
e,
slash,
downloader
skeleton.go,
and
it
implements
a
reverse
header
sync.
B
So,
before
the
merge,
when
we
try
to
sync,
we
will
just
ask
we:
can
we
can?
Basically
we
go
from
the
genesis
block
and
then
we
import
the
next
block
and
the
next
block
in
the
next
block
and
we
go
forwards
from
it
until
we
reach
the
current
head
and
if
we
see
some
some
block,
that
is,
that
has
a
higher
difficulty
than
than
what
we
currently
have
in
our
database.
Then
we
reorg
to
this
to
this
block,
but
because
we
don't
have
the
difficulty
anymore.
B
B
B
The
problem
is
these
these
these
testers.
They
didn't
have
a
beacon
chain,
so
the
beacon
chain
for
for
ethereum
maynard
has
been
running
for
for
over
a
year
now,
and
but
these
the
test
nets,
don't
have
beacon
chains,
and
so
we
need
to
set
up
the
beacon
chain.
We
need
to
deploy
the
beacon
chain
contract.
B
B
Basically,
it's
very
hard
to
find
companies
or
people
willing
to
run
validators
on
the
test
net
for
a
long
time,
and
this
is
something
that
we've
seen
with
with
gurley
all
the
time
is
companies
will
say
hey.
We
would
like
to
do
our
testing
on
gurley,
so
we
would
like
to
run
a
validator
on
gurley
and
we
will
set
up
a
validator
for
them
or
give
them
a
key
and
then,
after
like
half
a
year,
they
lose
interest.
B
They
they
shut
down
the
node
or
that
node
gets
is
not
updated.
It
doesn't
follow
the
chain
anymore
and
now
we're
stuck
with
one
less
validator
and
yeah.
We.
We
want
to
be
able
to
support
these
test
nets
for
the
users
so
that
the
users
can
actually
do
transactions
on
it.
And
if
there's
like
a
significant
portion
of
validators,
not
validating
anymore,
then
the
chain
can
not
continue
or
there's
like
lots
of
forks
and
stuff,
and
that's
that's
just
pretty
bad.
B
B
B
B
B
So
in
this
we
have
a
really
nice
graphic
here
from
from
etherworld,
and
it
has
the
four
girly
shadow,
forks
and
seven
maynard
shadow
forks
on
it
and
the
timeline
and
yeah
miniature
fox
7
is
happening
today
at
the
day
of
the
recording,
so
21st
or
22nd
of
june,
or
might
be
tomorrow.
We
don't,
we
don't
really
know
yet
but
yeah.
So
that's
that's
still
going
on
in
parallel
to
the
normal
test,
networking.
B
B
They
grew
so
big
that
it
it's
like.
You
need
to
think
several
hours
to
to
get
to
this,
to
get
these
test
nets
and
that's
kind
of
a
pain.
If
you
want
to
spin
up
a
note
and
and
just
see
that
everything
works
correctly
or
if
you
want
to
deploy
a
smart
contract
test,
something
and
don't
care
about
the
result
and
the
the
thing
is
like
people
actually
use
the
test
nets
for
for
basically
for
the
production
stuff,
and
that
is
not
great.
B
B
B
B
So
we
decided
to
have
the
rops
merge
extremely
early,
probably
a
like
from
from
a
software
perspective
a
bit
too
early,
but
fortunately
we
haven't
seen
any
big
issues,
so
it
wasn't
too
early
but
yeah.
The
idea
was
we're
going
to
make
this
as
early
as
possible
so
that
people
can
already
test
on
it
and
then
sepolia
basically
has
to
get
out
of
the
way.
We
just
need
to
do
it
at
some
point
and
for
gurley.
The
idea
is
we
want
to
fork
girly
with
the
with
the
final
versions.
B
B
This
heart
fork
only
pushes
the
difficulty
bomb
because
we
need
some
more
time
to
do
the
to
do.
We
don't
really
need
more
time
to
do
the
merge,
but
the
block
times
are
getting
already
getting
a
bit
long
and
we
want
to
have.
We
don't
want
to
have
a
degradation
user
experience
throughout
the
merge
and
that's
why
we
we
are
pushing
the
gray
glacier
a
bit
and
yeah.
B
We
don't
know
that
yet
and
of
course,
if
something
happens,
there
might
also
be
a
client
release
in
between
and
you
should
really,
if
you're
running
gas,
you
should
really
follow
at
underscore
ethereum
on
twitter.
This
is
where
we
post
about
client
releases
and
important
updates
and
things
that
you
should
just
know
about
all
right.
Let's
talk
about
issues,
robson
merge
issues,
so
we
did
the
robson
merch
and
the
merge
itself
went
extremely
good
for
for
us.
B
Basically,
we
specified
a
ttd
that
was
too
low
and
someone
started
mining
the
chain
with
a
lot
of
hashrate
and
so
the
ttd
occurred.
Basically,
the
merge
occurred
between
before
we
even
started
the
beacon
chain,
and
so
this,
like
basically
yeah.
We
couldn't
do
anything,
and
so
we
had
to
push
a
ttd
over
right
and
we
had
to
overwrite
the
ttd
to
a
very
high
value
and
then,
when
we,
when
we,
when
we
were
sure,
okay,
the
the
beacon
chain
was
started
now
and
it's
running
and
it
has
the
bellatrix
fork.
B
And
then
we
specified
the
correct,
ttd
and
basically
pushed
out
another
release.
And
then
the
merge
happened
during
the
merge
we
had.
We
had.
We
had
a
live
stream
with
the
guys
from
east
staker,
which
was
pretty
funny
during
the
time.
The
guest
guest
team
met
in
prague
for
east
prague,
which
was
a
really
nice
event,
and
so
we
took
the
the
week
beforehand
to
to
have
some
kind
of
offside,
and
so
we
had
the
live
stream
and
had
the
robson
merch
from
there.
B
It
took
a
long
time
to
create
these
new
blocks
so
machine,
the
other.
The
the
miners
kept
finding
kept,
finding
correct,
kept
correctly
sealing
the
blocks,
and
so
we
had
a
bunch
of
sibling
blocks
for
the
same
block
height,
so
we
had
five
or
ten
competing
blocks
all
mined
by
us,
and
so
the
network
kept
foggy
and
reorging.
B
Even
though
we
had
enough
hash
rate,
we
couldn't
actually
extend
the
chain
in
a
way
because
we
kept
working
on
these
different
forks
yeah.
So
so,
and
if
you,
if
you
watch
the
live
stream,
you
can
you
can
see
us,
we
had
a
camera
there
and
in
the
room,
you
can
see
us
scrambling
to
fix
it,
to
provision
another
machine
to
try
to
restart
gas
to
to
have
to
flush
out
some
of
the
some
of
the
events
from
the
event
cues
and
and
stuff
like
this.
A
B
B
So
hive
is
a
really
nice
platform
that
runs
that
continuously
downloads,
the
new
client
releases
and
whenever
we
push
to
master
in
guest-
and
it
has
a
lot
of-
we
have
a
lot
of
static
test
cases
there.
So
we
have
the
state
test
which
basically
test
all
the
evm
functionality
there.
I
think
it's
over
20
000
tests
or
something
like
this
and
we
have
for
the
for
the
for
the
merge.
B
B
We
have,
we
create
test
cases
that
mark
out
the
consensus
layer
and
we
will
ask
the
execution
layer,
hey,
execute
this
extremely
weird
block
and
if
the
exec
or
in
this
invalid
block
and
if
the
execution
layer
says
okay,
we
executed
this
block
correctly,
then
something's
wrong,
and
for
we
wanted
to
have
the
same
for
the
cl,
and
it's
not
so
easy
to
test,
because
the
the
communication
is
very
one
directional
between
the
cl
and
the
el.
The
cl
will
tell
the
el
to
do
something,
and
so
it's
very
easy
to
mock
out
the
cl.
B
But
it's
not
easy
to
mock
out
the
el
for
testing
the
seal.
So
that's
exactly
what
we
did.
We
basically
have
a
a
cl.
That
is
connected
to
a
proxy
that
is
connected
to
an
el,
and
this
allows
us
in
the
proxy
to
modify
the
results
that
we
get
from
the
the
execution
layer
client
to
to
to
do
interesting
tests.
B
B
Sufficient
attestations
and
and
thing
committee
participation
and
all
of
this
stuff,
so
that's
done
in
kurtosis,
and
then
we
also
have
antithesis
where
we
basically,
we
also
do.
We
do
the
same
thing,
but
it's
done
on
a
deterministic
hypervisor,
and
so
this
allows
and
basically
that
they're
using
some
some
breath
first
search
algorithm
to
find
crashes,
and
it
allows
them
to
like
this.
B
B
B
Then
you
could
crash
gath.
Fortunately,
we
found
this
via
manual
testing.
There
were
some
issues
with
async
production.
Basically,
we
have
these
two
calls,
prepare
payload
and
get
payload
and
prepare
payload
tells
the
execution
layer.
Client,
hey,
please
create
a
new
payload
with
these
parameters
and
then
get
payload
against
these
parameters,
and
in
the
beginning
we
did
the
synchronous
plug
production.
B
One
really
funny
bug
that
we
found
on
the
main
shadow
forks
was
that
the
default
gas
limit
in
geth
was
8
million
and
we
are
so
like
we.
We,
we,
like
everyone,
knows
that
right
now,
the
default
gas
limit
is
30
million
on
mainnet,
but
this
is
not
enshrined
in
the
code.
This
is
basically
just
what
the
what
the
miners
have
set
their
local
machines
to
to
this
30
million
or
the
mining
pools,
but
in
the
code
it
was
still
set
to
8
million.
B
So
when
we
did
the
first
minute
shadow
fork,
we
noticed
that
the
the
gas
limit
continuously
dropped
significantly
on
up
until
until
8
million
and
yeah.
Now
the
default
in
the
in
the
in
the
client
is
set
to
30
million
so
that
post
merge.
We
will
not
drop
the
gas
limit
significantly,
because
most
of
the
validators
will
not
set
the
default
guest
limit
to
something
different.
B
B
Oh,
we
had
we
had
a
bucket
that
was
within
a
so.
We
have
this
called
ex
this
ap
engine
api
call
called
exchange
transition,
configuration
which
basically,
it's
used
to
to
make
sure
that
the
consensus
layer
and
the
execution
layer
have
the
same
configuration
same
ttd
set.
If
we
push
a
block
override,
then
the
same
blocker
set
and
within
this
within
this
call,
we
had
some
error
and
the
error
message
was
hey.
B
But
I
I
mixed
up
the
which
ttd
was
which-
and
so
I
said,
the
beacon
ttd
is
what
actually
was
on
the
execution
layer,
ttd
and
the
execution
layer.
Ttd
is
what
what
actually
was
on
the
sorry
other
way
around,
but
yeah
you
get
what
I
mean.
So
it
was
the
consensus
layout
had
ttd
10
execution
layer
had
ttd
15,
and
the
arrow
was
a
mismatch
in
ttd
configuration.
B
Basically,
when
you
start
up
gas
with
a
ttd
override-
and
you
don't
have
anything
in
the
database
you're
starting
up
for
the
first
time,
then
the
ttd
override
will
not
be
applied
same
with
all
the
other
overrides
by
the
way.
It's
not
really
an
issue,
because
on
mainnet
you
would
never
start
up
a
client
with
a
ttd
override.
You
would
either
run
with
a
normal
ttd
or
if
you
set
the
ttd
override
you
will.
B
B
B
Basically,
you
need
to
shut
down
gas.
You
run
the
offline
pruner
that
will
delete
all
of
the
tri
nodes,
all
of
the
unnecessary
tri
nodes
and
you
you
will
free
up
a
lot
of
disk
space
and
then
you
can
start
up
gas
again,
but
these
these
unnecessary
try
notes
these
still
try
notes.
They
will
accumulate
over
time
and,
for
example,
if
you
go
to,
if
you
go
to
you,
can
you
can
really
see
that
this
is
really
good?
If
you
go
to
ether
scan,
they
have
some
really
nice
charts.
B
B
B
B
B
Then
we
need
to
do
the
shanghai
fork,
which
also
has
has
the
withdrawals
in
it
so
yeah,
except
for
the
reverse
diffs.
We
don't
have
a
lot
of
gas,
specific
features
that
we're
working
on
right
now,
because
there's
so
much
interesting
stuff
in
the
in
the
in
the
in,
like
for
the
ethereum
road
map
that
we
that
we
have
to
work
on,
and
it's
also
yeah.
B
B
I
hope
you
run
our
client,
but
I
also
hope
that
you
run
other
clients,
because
client
diversity
is
very
important
right
now,
too
many
people
run
gas
very
honored
that
so
many
people
put
the
like
trust
us
and
trust
our
software,
but
the
other
clients
also
build
pretty
good
software,
and
so
you
should
try
them
out,
and
you
can
also
run
two
clients
and
have
a
proxy
in
between.
There
are
some
projects
trying
trying
to
do
this,
especially
if
you're
a
bigger
staking
providers.
B
A
A
B
Yeah,
so
the
fuzzing
has
been
really
nice.
We
found
some
issues
in
the
in
the
early
beginning
with
the
with
the
engine
api
fuzzer,
especially
on
death
and
nether
mind
so,
for
example,
nethermine
could
produce
both
nether
might
and
and
be
so
could
produce
blocks
that
they
could
not
insert
themselves.
B
I
think
that
our
hash
was
replaced
with
our
parent
hash,
and
so
because
some
clients
had
some
caching
mechanism.
They
wouldn't
verify
that
our
hash,
so
the
block
hash
was
correct
and
they
would
first
of
all
look
it
look
it
up
in
the
database,
but
because
the
parent
was
already
in
the
database,
we
would
see
hey.
This
block
was
already
in
the
database,
so
we're
going
to
accept
it,
even
though
the
block
was
malformed
and
the
hash
was
just
replaced
with
the
parent
hash,
and
this
led
to
some
consensus
issues.
A
A
Yeah
right,
this
is
one
of
the
biggest
upgrade
I'm
assuming
so
it's
good
to
have
it
as
firm
as
it
can
be.
You
mentioned
about
shadow
forking.
We
have
done
like
six
and
seventh
is
today
or
tomorrow
you
mentioned
in
the
presentation.
What
is
the
main
reason
for
continued
shadow
fork
and
how
many
more
shadow
folk
can
we
expect
in
future.
B
So
we
roughly
plan
to
do
one
every
week.
It
just
gives
us
a
really
good
confidence
in
everything.
It
lets
us
run
through
the
transition
over
and
over
again
and
see
that
everything
works
and
if
we
see
issues
or
if
we
see
regressions
or
if
we
see
some
problems
on,
for
example,
on
robson,
we
can
also
test
the
same
same
thing
on
on
the
manhattan
shadow
fork
and
and
and
see
that
that
this,
the
these
issues
have
been
have
been
fixed.
B
It
so
shadowfox
have
this
huge
advantage
that
we
we're
using
real
transactions,
we're
using
real
estate
syncing.
A
note
on
the
shadow
fork
gives
us
a
good
indication
on
how
it
would
be
to
sync
a
note
on
the
post
merge
chain.
So
we
can
also
do
a
lot
of
like
benchmarks
and
just
tests
to
see
that
everything
will
work
as
expected,
post,
merge
and
that
that
it's
it's.
It's
really.
A
That
is
nice,
I
mean
with
so
many
things
going
on
if
we
can
automate
something
or
simplify
something
good
for
the
developers
right.
One
other
thing
are
like
mattresses.
I
have
seen
that
during
the
altair
upgrade
the
beacon
chain
upgrade.
They
were
talking
about
a
lot
of
matrices.
We
had
a
chat
with
paritos
and
leonardo
on
beconchained
metropolises,
I'm
assuming
that
there
are
matrices
being
taken
care
here
in
the
merge
upgrade
as
well.
B
B
We
also
have
metrics.
We
have
a
lot
of
metrics
for
the
download,
like
the
downloaded,
the
synchronization
part
and
for
the
the
execution
part,
and
that's
also
very
like
it's.
It's
very
interesting
and
important
to
also
look
at
these
and
on
some
of
the
the
main
shadow
folks.
We
took
a
look
at
them
and
just
to
make
sure
that
block
processing
doesn't
magically
become
extremely
difficult
from
now
on
and
that
everything
is
basically
the
the
same
as
it
as
it
was
right.
Now
we
have
a
lot
of.
A
B
So
for
the
girly
part,
no,
I
think
peritosh.
You
would
have
to
ask
peritosh
about
that.
He
he
he
knows
more
about
the
the
the
prata
than
I
do,
but
I
think
they
they
looked
at
how
many
validators
are
run
by
us.
So
the
core
devs,
the
different
client
teams,
and
how
many
validators
are
run
by
the
community.
A
All
right
I
mean
undoubtedly
marius
and
paritos,
along
with
all
other
depths
involved
in
testing
the
merch
are
heroes
of
ethereum
community.
For
our
listeners
we
have
recorded
an
in-depth
conversation
with
marius
and
paritos
on
godly
test
rate
and
shadow
forking.
So
if
you
have
missed
watching
it
earlier
check
out
episode,
63
on
keep
an
eye
marius.
I
have
couple
of
more
questions.
We
can
probably
go
with
them
quickly,.
A
That's
awesome,
so
I
I'm
wondering
about
the
client
combination
you
mentioned
earlier,
like
there
would
be
now
a
validator
has
to
go
with
both
el
n
client.
What
do
you
think
would
be
the
best
client
combination
for
get
or
is
there
something
called
as
the
best
client
combination
or
you
think
it
is
going
to
be
similar
with
any
of
the
els.
B
B
A
Awesome
so
yeah
just
pick
one.
While
we
are
talking
about
client
diversity
here,
el
clients
will
not
be
the
decision
maker
for
a
new
block
or
inclusion
after
the
merge.
So
in
your
opinion,
will
it
change
the
chart
of
client
diversity
or
do
you
think
death
will
be
the
majority
client
even
after
the
post
march.
B
I
hope
that
other
clients
will
have
greater
share
than
they
have
right
now
with
open
ethereum,
not
going
through
the
merge.
I
hope
that
aragon
will
probably
take
a
lot
of
the
client
share
of
open
ethereum.
That
would
be
really
nice.
I
hope
that
the
people
that
run
open
ethereum
will
not
switch
to
gas
so
that
we
will
have
a
bigger
share.
B
Without
so,
you
can
run
notes
without
having
to
stake,
and
so
the
staking
pool
should
run
all
20
client
combinations
and
then
point
their
validators
to
one
and
in
the
in
the
case
of
something
happening.
They
should.
They
can
then
point
their
validators
to
another
one,
and
it's
not
that
hard
to
run
all
20
client
combinations.
A
Yeah,
I
hope
so
this
client
diversity
thing
I
I
have
seen
that
in
the
cl
side,
it
is
getting
a
good
picture
now.
I
hope
something
works
for
the
el
clients
as
well,
and
it
gets
a
good
picture.
Even
I
forget
is
a
major
client
shareholder.
The
difference
between
gap
and
the
second
client
should
not
be
that
big
all
right.
My
one
question
about
the
personal
experience
as
a
developer.
A
B
B
B
I'm
I'm
just
going
to
take
it
over
is
that
is
that
fine,
for
you
guys
and
I
updated
our
implementation
to
the
to
the
new
spec,
and
this
gave
us
a
really
good
head
start.
So,
basically,
our
implementation
was
mostly
working
on
the
first
day,
and
so
we
could
work
with
the
other
cls
to
with
the
cls
to
to
make
the
interoperability
working
pretty
well
and
yeah.
It
was.
Greece
was
just
an
incredible
event.
B
B
That
was
that
was
incredibly
great
at
this
event,
and
it's,
I
think
it
cut
down
that
the
time
to
the
merge
by
at
least
six
months,
and
afterwards
we
had
a
lot
of
these
shadow,
forks
and
and
test
nets
and
and
stuff
going
on,
and
that
was
that
was
also
incredibly
nice
yeah.
It's
it's
been
a
really
good
journey,
but
I
also
hope
it
comes
to
an
end
soon.
B
For
me,
I'm
I
think
if
we
can,
if
we
can
do
the
same
thing,
that
we
do
right
now,
but
by
using
less
energy
that
is
really
really
incredible,
and
if
right
now,
ethereum
preduces,
roughly
20
000
tons
of
co2
every
single
day,
and
I
have
the
feeling
if
I
like,
if
I,
with
my
own
work,
can
make
this
can
even
influence
the
the
merge
by
one
one
day.
I
I
basically
have
the
co2
budget
for,
for
my
whole
life
saved,
and
that
is
just
an
incredible
feeling
and
yeah.
B
A
Nice-
that's
that's
quite
nice,
thought
of
decreasing
the
co2
of
the
environment,
plus
all
the
hard
work.
We
really
appreciate
that
I
have
heard
similar
stories
about
having
in-person
meeting
for
testing
and
definitely
introduced
the
work,
the
timeline
that
otherwise
it
would
have
been
well.
Thank
you
so
much
for
all
your
time.
It's
time
for
wrap-up
anything
else
that
you
would
like
to
share
with
our
listeners
in
terms
of
supporting
ethereum
clients
or
supporting
the
upgrade
in
general.
B
B
If
you're
running
a
validator-
and
you
want
to
learn
how
all
of
this
stuff
works
then
go
to
robston
deposit,
some
robson
eth,
there
start
up
your
validator
and
test
it.
You
can
test
it
already
on
robson
and
it's
it's
super
easy.
It's
basically
the
same
thing
as
you
already
did
on
mainnet
if
you're
running
a
metadata
and
if
you
are
a
service
provider
at
any
sorts,
go
test.
Your
software
on
robson.
A
A
Go
ethereum
is
the
leader
with
the
80
percent
share
on
the
execution
layer.
Client
demographic
certainly
provide
confidence
to
an
ethereum
node
runner,
but
this
also
increases
pressure
on
client
developers
to
maintain
the
client
generally
they
are
under
appreciated.
My
wish
is,
with
this
star
users
may
learn
about
get
client
as
an
execution.
Client
run
a
note,
participate
in
the
network
and
also
be
appreciative
of
the
hard
work
that
is
being
put
in
by
the
team,
and
on
this
note,
thank
you,
everyone
for
watching
and
listening
this
special
episode
on
merge.