►
Description
Topics covered
-----------------------------
0:51 - Client introduction
1:31 - Guest’s introduction (Andrew)
1:53 - Guest’s introduction (Igor)
2:29 - About Erigon
3:32 - Erigon’s distinctive features - Database, State sync, Modular architecture
4:42 - Akula & silkworm
6:44 - Erigon doesn’t support mining, does Akula or Silkworm support it?
8:57 - Transaction pool separation in Erigon
10:02 - Will Akula be attracting Open Ethereum users?
11:43 - Akula & Silkworm vision
13:52 - Who are current users and strengths of Erigon?
15:00 - Erigon 2
16:46 - How does the team manage different client releases?
19:23 - When is Erigon 2.0 expected?
21:29 - Any specific instruction for current or new node operator
24:07 - Checkpoint sync
26:44 - Who is the main user base for Erigon?
31:27 - Merge testnet & shadow fork - How is Erigon performing with CL clients
36:50 - Peering issue occurred in SF7 or earlier?
37:40 - Nimbus & Erigon
38:00 - How is the performance of Erigon with other CL clients?
40:46 - Are there any learning experiences during the testing merge period?
47:00 - A story from testing the merge
49:17 - What are your expectations from the community? What about the EF client incentive program?
53:56 - Open source contribution
56:17 - Client diversity
Resources:
-----------------
Substack (Erigon) - https://erigon.substack.com/
Discord (Erigon) - https://discord.gg/RH5mmdC4
TheMerge playlist - https://www.youtube.com/playlist?list=PL4cwHXAawZxqoLxXqZqT4hcYhoHoP6w12
KnowYourClient - https://www.youtube.com/playlist?list=PL4cwHXAawZxoruie1hmYWJfiakpYivXft
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
PEEPanEIP playlist - https://www.youtube.com/playlist?list=PL4cwHXAawZxqu0PKKyMzG_3BJV_xZTi1F
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
Client
diversity
is
a
challenge
that
ethereum
community
is
willing
to
overcome
to
help
users
know
more
about
ethereum's,
el
and
cl
climbs
available
to
run
a
node.
Ech
brings
to
know
your
client
series
welcome
to
the
mud.
Special
p
penny
episode,
77,
I
am
pooja
ranjan
and
with
me,
is
talented
ethereum
developer
andrew
ashman
to
talk
about
the
erikan
client
and
igor
mandergen
from
the
team.
A
As
per
the
official
documentation,
arrigon
is
an
implementation
of
ethereum
on
the
efficiency
frontier
written
in
go
andrew
has
been
on
our
show
earlier
to
talk
about
eip3607
the
client
implementation,
yellow
paper
changes
with
respect
to
the
proposal
in
episode,
49
check
out
the
link
in
the
description
below
we
are
looking
forward
to
learning
more
about
the
client
and
its
progression
towards
the
proof
of
stake
world.
In
this
episode,
may
we
kick
off
with
a
brief
introduction
for
our
new
listeners,
igor
and
andrew.
C
Yeah
and
my
name
is
igor-
I
also
started
working
on
erigon
in
second
half
of
2019.
I
looked
up.
My
first
commit
actually
to
find
this
information,
but
and
right
now,
I'm
also
helping
marigold
a
little
bit
and
also
having
my
own
little
startup,
that's
running,
notes
and
whatnot.
So
I
think
some
questions
could
be
quite
relevant
to
me.
B
B
C
Yeah-
and
I
would
add
a
little
bit
that
there
are
three
probably
distinctive
things
that
ericon
does
differently
from
other
clients
that
I
can
mention,
so
the
first
is,
of
course,
the
database
layout.
That
ends
you
already
mentioned.
The
second
is
the
stage
sync
architecture.
When
the
scene,
it
doesn't
think
the
same
way
as
others,
so
instead
of
it
splits
it
into
like
formal
stages
and
processes,
data
in
bulk
and
the
third
one
is
the
modular
architecture.
C
That's
way
more
akin
to
how
east
ii
or
beacon
chain
clients
are
written.
When
you
have
like
separate,
let's
say:
validator
client,
separate
wallet,
separate
beacon,
node.
So
in
our
case
we
have
the
whole
architecture.
That's
called
thorax.
I
think
still
calls
like
this.
When
we
have
a
separate
downloader,
separate
sentries
separates
rpc
demon
and
whatnot,
so
those
are
the
kind
of
differences
and
silkworm
and
akula
are
actually
re-implementation
the
same
architecture
in
different
languages.
Basically,.
A
B
Yes,
so
akula
is
a
rust
implementation.
Its
main
developer
is
artem
baratnikov,
who
used
to
be
a
team
lead
at
open
ethereum.
So
we
have
kind
of
three
projects.
Aragon
is
our
flagship
project
written
in
goal
and
which
is
the
most
complete
and
mature
project
of
the
three,
and
we
also
have
silkworm
in
c
plus
and
akula
in
in
rust.
B
Silkworm
and
akula
are
still
not
not
as
mature
as
aragon,
both
in
in
akula
and
silkworm.
They
started
as
greenfield
projects
from
scratch.
They
have
the
apache
license,
they
might
make
them
a
better
suit
for
commercial
applications,
and
they
should
be
also
easier
to
understand
because
because
the
the
code
base
is
is
new
and
doesn't
contain
a
lot
of
legacy
features
and
both
both
silkworm
and
akula
should
be
ultimately
should
be
faster
than
arigon,
because,
unlike
go,
there
is
no
garbage
collector.
C
Yeah,
I
would
also
say
that
aragon,
as
andre
mentioned,
it
still
contains
a
lot
of
traces
of
us
figuring
things
out
and
usually
akula
and
silkworm.
They
follow
and
already
figured
out
how
to
do
things
the
most
efficient
way.
So
usually
it
takes
a
couple
of
iterations
on
top
of
aragon,
and
then
it
comes
to
those
so
yeah.
A
B
Well,
so
we
in
in
aragon,
there
was
an
experimental
support
of
etihash
mining,
but
without
any
gpu
mining
support
and
but
with
with
the
merge
with
the
transition
to
proof
of
stake,
aragon
will
fully
support,
block
building
and
right
now
it
also
supports
my
click.
Click
mining.
So
you
and
it
also
supports
et
hash
mining.
B
But
it's
not
practical,
because
because
there
is
no
gpu
acceleration,
but
after
the
merch
yeah
aragon
will
be
a
fully
fledged
in
terms
of
block
building
as
well
and
as
to
silk
rum
and
akula.
I
don't
think
I
know
there
is
no
mining
support
in
in
silicon
yet
and
probably
not
in
a
cooler
either,
but
that's
something
that
we
should
add
at
some
point.
C
Know
I
think
it's
also
historically
transaction
pool,
which
is
important
component
of
any
mining
thing,
was
the
last
thing
we
kind
of
get
around
to
just
remembering
that
arigon
started
as
a
very,
very
small
team,
so
we
focused
and
the
majority
of
clients
that
run
nodes.
They
don't
really
mind
things,
so
we
focused
on
sort
of
the
80
80
of
the
things
that
people
are
actually
need,
and
then
we
kind
of
we
had
to
put
aside
mining
for
a
bit
of
a
longer
time
and
again,
with
the
merge
coming
right.
C
B
Also,
I
would
like
to
add
that,
with
this
transaction
for
separation
in
in
aragon,
it's
actually
it
the
this.
What
iger
mentioned
that
in
aragon,
we
try
to
separate
big
components
and
transaction
four
is
one
such
component
and
with
this
separation
it
potentially
allows
us
to
protect
our
nodes
nodes
against
malicious
transactions.
A
That
is
awesome
just
follow
up
on
that.
I
understand
this
is
currently
not
supporting
and
it
started
as
a
small
team.
But
if
you
look
into
the
current
picture
of
the
demographic
of
client
diversity
here,
erigon
actually
stands
on
the
second
position
and
after
open
ethereum
when
it
is
like
not
supporting
any
further
upgrade.
Do
you
think
the
version
of
akula
may
be
helpful
to
get
more
users
adding
to
the
aragon
community.
C
I
think,
like
it's
a
bit
of
a,
I
think
the
the
reason
why
at
least
we
like
as
an
old
runner
and
I
used
open
ethereum
always
was
not
because
it's
written
in
rust,
but
because
it
has
tracing
apis
that
are
fast
and
that
thing
is
more
or
less
fully
supported.
I
think
it's
fully
supported
in
every
one
already
and
it
will
be
supported,
of
course,
in
the
the
forks,
so
it
doesn't
really
matter
which
one
will
you
run
later
on?
C
If
you
really
want
a
rust
client,
then
probably
yes,
it's
great
to
to
wait
for
a
cooler.
But
if
you
want
tracing
today,
you
can
might
as
well
just
run
airborne
and
yeah
you'll
have
the
same
openness
here
on
tracing.
We
ended
up
even
like
having
some.
I
remember.
We
used
to
have
some
flags
to
even
repeat
some
bugs
from
open,
ethereum
tracing,
so
they're
like
100
percent
compatible,
even
though
it's
maybe
not
totally
correct
traces.
C
C
Basically,
like
I
would
say,
that's
already
like
running
quite
quite
a
few
nodes
with
even
erico,
and
it
gets
quite
a
bit
of
more
like
requests
per
second
from
a
node.
One
like
typical
is
calls
for
any
bigger,
defy
application
than
other
nodes
that
we
can
compare
with,
and
I
think
we
test
it
with
silk
rpc.
B
To
tell
who,
who
are
the
our
currently,
who
are
the
users
of
aragon
and
what's
its
current
strengths?
Well,
our
strength
number
one
is
of
course,
full
archive
nodes,
because
the
disk
footprint
is
around
two
terabytes.
While
if
you
want
a
full
archive
node
with
a
guest,
that's
maybe
10
10
terabytes.
So
that's
our
strength
number
one
and
our
weakness
is
that
we
only
support
sync
from
genesis.
B
B
We
call
them
aragon
2,
but
it
will
be
not
a
single,
a
upgrade
but
a
series
of
upgrades,
including
fundamental
database
and
data
access
re-architecture,
and
we
already
started
moving
in
in
this
aragon
to
series
of
upgrades.
We
introdu
introduced
torrent,
sink
of
blocks
of
all
aragon
blocks
and
we
want
to
utilize
the
torrent
technology
for
our
think
more
persists.
B
B
A
Awesome,
that's
quite
interesting,
introduction
around
the
client
and
all
the
options
those
are
available
for
users,
because
this
is
much
special.
So,
let's
move
towards
upgrade
and
merge
related
questions
before
we
jump
into
much,
I
know
grey
glacier,
which
is
expected
tomorrow
or
day
after
tomorrow.
In
a
couple
of
days,
I
wonder
how
do
you
guys
see
different
client
releases
in
between
the
march
and
other
upcoming
upgrades.
B
To
answer
your
questions
about
question
about
releases
right
now
we
have
two
flavors
of
aragon
releases.
We
have
older,
more
stable
aragon,
beta
releases
that
were
created
before
the
the
the
the
the
are
gone
to
re-architecture
work
started,
so
these
are
more
stable
and
but
the
the
we
then
they
are
not
going
to
be
to
be
merged
compatible,
so
you
can
use
them
for
a
grey
glacier
and
so
for
grey
glacier.
You
have
two
options
you
can
download.
B
B
C
Basically,
the
the
old
beta,
the
version
is
by
the
way
2022
0405
deprecated,
and
it
basically
ends
after
the
great
glacier
is
done.
So
when
the
merge
happens,
it
won't
be
supported
anymore
and
the
only
version
that
goes
and
supports
the
merge
will
be
so
called
are
going
to
currently
in
the
alpha
channel
so
yeah
and
yeah.
That's
what
we
run,
for
instance,
on
the
for
the
tesla
validators
already
for
the
devnet,
for
shadow
forks
and
and
things
like
that,.
B
B
C
C
Already
are
in
the
process
of
like
stabilizing
the
the
current
version
of
like
yeah,
2.1
or
2.0.
If
you
want,
there
are
gone
too,
so
it
will.
Yeah
will
come
with
the
merge,
like
you
can
already
test
it.
It's
just
yeah,
it's
a
it's
a
no!
We
I
mean
we
are
trying
to
be
quite
strict
about
laboring
things,
so
we're
labeling
it
alpha,
because
we
know
that
there
are
some
known
issues
within
it.
A
So
I
have
a
follow-up
question
here.
We
mentioned
about
stabilizing
the
current
version
of
aragon.
Are
there
any
specific
instruction
or
specific
points
to
be
noted
by
node
operators,
while
they
are
upgrading
their
notes
for
a
much
or
even
after
mud,
someone
wants
to
join?
Are
there
any
special
instructions
for
them.
C
Apart
from
that,
like
I
didn't
notice,
much
difference
between
running
the
aragon,
one
note
versus
arigon
two
note
in
the
merge
configuration
that
with
a
couple
of
kvs,
that's
of
course,
they're
going
to
is
a
little
bit
less
stable
right
now
like
there
are
a
couple
of
things
that
needs
to
be
fixed.
I
think,
and
also
that
as
soon
as
it
switches
to
like
the
after
post
merge,
it's
it's
a
bit
slower
to
sing
than
before
that,
because
we
cannot
well
right
now.
I
don't
think
like
it's.
C
It's
probably
should
be
supported
that
the
checkpoints
thing,
but
right
now
it
just
seems
blocked
by
block.
So
it's
a
bit
inefficient
in
terms
of
catching
up
with
the
network,
but
then
you
still
get
the
same
performance
same
good
performance
on
the
rpc
side
at
least
I
didn't
notice
any
difference
between
the
in
the
performance
of
rpcs
of
like
old
arrigon
and
urigon
underload,
so
they
both
behave
quite
quite
nicely.
So
yeah,
it's
it's
not
that
much
of
a
difference.
C
One
one
thing
that
you
need
to
note
that
between,
if
you
run
the
older
ago,
like
the
beta
version
and
the
currently
deprecated
version,
the
databases
are
not
compatible,
so
you
will
need
to
re-sync
the
the
nodes
like.
But
what
I
do
like
as
a
let's
say,
an
old
operator.
I
usually
think
one
note
do
a
snapshot
of
the
drive
and
then
just
clone
it
to
make
multiple
nodes.
C
So
it's
usually
another
problem,
and
this
thing
is
usually
automated
and
anybody
who
runs
like
more
than
three
to
four
holes
and
if
you
just
run
three
to
four,
you
can
just
re-sync
them
from
scratch
and
a
bittorrent
thing.
It's
also
makes
it
a
bit
faster
on
the
on
the
downloading
data
side
and,
of
course,
it
also
prepares
us
like
they're,
going
very
good
to
the
I
forgot.
C
B
B
B
C
I
almost
forgot
one
more
thing
that
you
need
to
note:
actually,
if
you're,
a
node
operator
and
you're
switching
from
the
old
airborne
like
pre-motion
to
the
post
merge
is
that
right
now
the
we
used
to
run
our
pc
daemon
by
default
as
an
outside
process
and
right
now.
It's
also
built
in
and
enabled
by
default,
to
simplify
the
setup,
because
so
you
don't
have
to
jiggle
like
more
containers
that
you
need
or
more
process
that
you
need.
C
That
means
that
if
you
can
just
by
default,
you
will
have
rpc
demand
built
in
in
aragon,
just
like
you
haven't
yes
or
other
clients,
but
you
can
still
run
it
separately.
But
just
you
need
to
make
sure
that
there
you
need
to
disable
the
internal
one.
Otherwise
they
will
conflict
on
ports.
So
that's
a
small
thing.
A
C
Yeah,
like
we
are
again
as
a
node
operator.
If
we
need
to
scale
the
right
now
for
obstacles,
we
want
to
scale
more
nodes.
We
definitely
do
checkpoint
sync
to
our
own
neighbor
nodes,
because
otherwise
it
takes
not
forever
to
think
of
another
episode.
It's
like
relatively
slow
and
everyone's
like
very
quickly
to
get
like
from
five
nodes.
To
let's
say
20
like
without
checkpoint,
sync
is
gonna,
be
quite
sluggish.
A
Talking
about
node
operators,
I
may
be
missing
something
here,
but
help
me
understand.
Who
are
the
main
target
users
here,
like
what
kind
of
people
should
be
running?
Arygon
node?
I
understand
it
is
not
supporting
proof
of
work,
but
it
will
be
as
good
as
any
other
client
of
execution
layer
post
merge,
but
so
far
what
was
the
main
user
base
for
ericon?
I.
C
Can
answer
some
of
this,
like
anybody
who
runs
quite
a
lot
of
nodes,
gets
economies
of
scale
better,
especially
when
executing
these
calls.
That
could
be
your
typical
infrastructure
providers
like
fuera
or
like
alchemy,
or
whoever
also
bigger,
defy
players
if
you're
taking
like
about
exchanges
and
whatnot,
so
they
do
tons
of
requests
like
tones
like
thousands
and
thousands
requests
per
second,
who
knows
and
the
the
reason
that's
with
aragon
they
might
have
to
do
to
have
like
four
times
or
three
times
less
nose
to
to
achieve
the
same
performance.
C
C
It
cannot
be
left
in
the
inconsistent
state,
and
that
means,
if
you
stop
the
node,
to
make
a
snapshot
to
like
create
more
nodes
like
if,
if
you
do,
I
do
it
with
some,
especially
on
some
other
blockchains
like
ethereum,
is
fine
but
like
on
some
other
blockchains
into
like
stop.
The
node
wait
like
a
minute
to
make
sure
that
everything
is
written
to
disk
for
sure
and
only
then
clone
the
drive,
because
otherwise
you
will
end
up.
The
notes
will
not
start
because
it
was
not
completely
written
in
consistent
state
with
every
bone.
C
We
can
just
kill
the
nose
snap
shot
it
like
and
just
run
it.
So
it's
it's
way
more
and
also,
if
somebody
needs
them
again,
it's
more
for
the
d5
players.
Sometimes
they
do.
You
know
analytics
on
the
chain
and
they
need
tracing
of
the
historical
data
and
I
think
carigo
with
certain
archival
data
is
so
far
the
best
with
both
like
small
data,
smaller
data
snapshots.
Basically,
footprints
are
like
basically
under
two
terabytes
for
the
full
archival
data
with
tracing
on.
So
that's
also
is
interesting.
C
So
that's
for
the
bigger
player
for
the
home
enthusiast.
I
think
that's
gonna
be
interesting
when
the
bittorrent
thing
will
become
the
bigger
one,
because
right
now
he
still
needs
to
re-execute
all
the
transactions,
but
I
mean
it's
still
cool
that
I
have
a
laptop
here
that
I'm
speaking
to
you
from
right
and
I
have
a
full
archival,
ethereum
node
on
this
laptop
like
as
a
basically
individual
of
course.
Here
it
takes
a
lot
of
space
like
and
it's
not
a
cheap
laptop
configuration,
but
still
it's
a
laptop.
C
It's
not
something
you
need
to
buy
in
the
server
rack
or
something
like
this
for
the
cooler
kind
of
thing.
So
those
are
the
things
that
come
to
mind.
Oh
yeah,
one
more
thing,
that's
very
important!
You
shouldn't
underestimate
the
pruning
that
we
have,
because
our
pruning
is
how
to
say
it
is
deterministic.
C
So
you
know
how
many
blocks
of
history
you
keep
behind
and
it's
super
important,
let's
say
again,
there's
a
little
trick
like
if
you
want
to
provide
an
archival
node,
but
not
everybody
is
using
archival
mode,
it's
very
expensive
to
run
archival
out.
What
you
do
is
you
route
requests
that
are
non-archival,
even
if
you
think
that
you
know
that
is
archival
as
a
like,
as
an
infrastructure
provider,
you
route
another
calorie
request
to
non-archival
nodes
and
archival
requests
to
their
travel
nodes.
C
But
how
do
you
know
which
ones
are
archival
or
not
by
the
block
number
and
knowing
to
which
block
our
archival
nodes
are
pruned?
It
makes
the
logic
very
simple,
so
I
know
that
okay,
we
keep
lost
six
thousand
blocks
or
something
like
this
in
in
the
change
he's
six
thousand
history
items.
So
if
you
have
an
rpc
call,
that's
request
more
than
that.
It
goes
to
archival
and,
like
99.9
requests,
never
ask
anything
more
than
that
and
they
go
to
non-archival
mode.
C
And
that
way
we
can
keep
like,
let's
say,
20,
non-archival
notes
and
only
one
archival
and
still
have
the
clients
happy
who
want
archival
access
because
they
usually
want
it.
Rarely.
So
that's
also
one
of
the
interesting
thing
with
some
other
clients
when
it's
non-deterministic,
it's
very
hard
to
figure
out
like,
but
it's
dependent
on
memory
or
something
it's
very
hard
to
figure
out
when
to
route.
Those
requests
it's
just
like
my
a
little
bit
node
operator
inside
baseball.
If
you
want.
A
I
know,
generally
speaking,
it
is
recommended
like.
If
someone
is
running
a
validator
node,
then
they
should
have
multiple
nodes
running
just
to
have
an
in
case
of
emergency.
They
can
switch
to
another
client
so
for
that
argon
is
always
there,
but
I
was
just
curious
well
moving
on
to
test
nets
and
shadow
forks
that
are
happening
with
respect
to
the
merge
upgrade.
A
My
understanding
is
ignoring
a
few
bugs
and
issues
which
may
occur
with
any
other
client.
Ericon
has
been
one
of
those
clients,
those
participated
in
almost
every
test
net.
Would
you
maybe
like
to
talk
about
the
performance
of
erigon
and
the
merged
testnet
so
far,
and
how?
Generally
speaking
it
is
interacting
with
the
interop
session,
with
the
consensus
layer,
clients.
B
Well,
I
think,
for
for
the
recent
in
the
recent
test
nets,
aragon
has
been
doing
more
or
less
fine.
We
had
an
issue
where
we
created
as
a
validator.
We
created
blocks
with
no
transactions
that
that
has
been
fixed
and
we
are
monitoring
whether
it
occurs
and
or
not.
But
so
we
are
keeping
close
eye
on
that.
B
There
was
an
issue
in
shadow
forks,
not
in
testness
like
like
killing
or
robsten,
but
in
shadow
forks,
because
shadow
forks
are
different
in
when
the
merge
happens
on
main
on
the
main
net.
There
will
be
at
some
point,
probably
after
the
merge
there
will
be
a
so-called
merged
net
split
block
and
it'll
fork.
The
nodes
that
haven't
enabled
the
the
transition
from
the
rest
of
from
from
like
the
the
mainnet
but
on
on
shadow
forklift,
is
that
you
do
not
do
that.
B
B
The
one
workaround
for
aragon
is
to
actually
to
specify
aesthetic
piers
that
from
the
the
correct
shadow
fork,
so
that
you
at
least
you
have
some
peers.
Otherwise
I
mean
the
idea,
the
idea
for
shadow
foxes.
Also,
you
don't
want
to
filter
out
peers
because
you
want
to
receive
transactions
from
the
mainnet,
but
on
the
other
hand,
all
your
all
those
fears
they
have
a
totally
different
worldview.
They
see
totally
different
blocks
and
it's
a
bit
schizophrenic
right.
So
this
shadow
folks
issues
yeah.
They
are
they're
a
bit
nice.
C
Yeah
and
and
speaking
of
like
running
the
the
tesla
specifically
I've
been
running
kiln
validators
I've
been
running
quite
a
bit
of
ropes
and
validators,
and
so
far
it's
been
like
fine
again,
there
are
some
bugs
that
are
specific
to
everyone
that
are
not
specific
to
merge.
That
sometimes
requires
to
like
restart
the
arigon,
but
that
has
nothing
to
do
if
you
run
it
with
non-merge
configuration
on
the
main
net,
it
has
the
same
bug,
so
it's
not
non-nurse
specific
but
other
than
that
again.
We're
monitoring
right
now.
C
C
Currently
I
run,
I
think,
to
post
merge
consensus
layer,
clients,
namely
taco
and
nimbus,
just
because
again
prisma
is
already
big
like,
so
we
are
trying
to
do
a
little
bit
more
like
niche
consensus
player
clients
at
this
time,
trying
to
to
run
them,
and
I
just
like
I
disclaimer-
I
used
to
work
at
status
at
some
point
in
time.
So
I
still
have
some
warm
feeling
towards
the
team
and
and
whatnot.
So
that's
why
I
named
us
in
particular
and
so
far
I
had
pretty
good
experience
with
them.
C
A
Absolutely
that's
the
whole
purpose
of
having
all
these
tests
and
shadow
forking
has
been
a
boon
like
we
can
do
it
multiple
time
with
same
configuration,
just
changing
it
like
every
time
dealing
with
the
issues
that
happen
in
the
last
time.
So,
if
I
understand
correctly,
the
issue
that
andrew
was
explaining
just
now
is
that
the
peering
issue
you
mentioned,
and
if
so
did
that
happen
for
shadow
force
seven
or
had
it
happened
earlier
as
well.
B
A
I
understand-
and
the
resolution
is
also
quite
handy
at
static
notes.
It's
helping
in
testing
that's
useful,
I'm
talking
about
the
status
and
numbers.
I
can
understand
your
interest.
We
had
a
chat
with
a
team
of
status
and
they
are
also
like
storage
efficient
clients.
So
I
can
understand
the
relation
between
erican
and
numbers
over
there.
Yeah.
C
I
noticed,
for
instance,
that
the
cpu-wise
and
nimbus
really
has
wants
less
resources
than
especially
psycho.
I'm
not
just,
but
just
is
just
if
you
even
comparing
like
like
lighthouse
that
is
rust.
It's
a
very
efficient
language,
nimbus's
name
is
very
efficient.
Language
prism
is
go
which
is
efficient
but
still
have
garbage
collections.
So
you
take
it
with
a
little
bit
of
star
in
java
or
like
what
is
it
written
in
kotlin
or
whatever,
but
gvm
basically
has
even
slower
garbage
collection.
C
So
so
we
specifically
play
with
seko
and
nimbo,
says
kind
of
opposite
spectrum
if
you
want
of
like
cpu
usage,
but
tech,
on
the
other
hand,
is
like
you
see
that
they're
very
targeting
the
enterprise
users
with
all
these
fancy
health
checks
that
they
have
like
nice
summaries
and
the
load
so
they're
very,
very
easy
to
plug
and
play
into
if
you
want
a
kubernetes
cluster
or
like
into
like
nomad
clusters
or
something
like
this.
So
it's
also
interesting.
A
So
it
is
good
to
know
like
take.
One
numbers
are
the
two
common
cl
that
is
being
used
in
combination
with
the
aragon,
so
this
can
be
a
favorite
of
yours.
I'm
just
curious
to
understand,
like
with
other
client
combination,
the
other
cl
client
combination,
the
performance
of
arigon
is
generally
the
same,
or
are
there
any
advantages
of
using
takeover
numbers?.
C
C
Maybe
ten
or
more
tequila
nimbus
instances
didn't
notice
much
specific
differences,
but
I
didn't
like
we
also
run
prism
on
the
pre-merge
like
beacon
chain
magnet
for
the
data,
so
with
arigon
as
a
just
is
one
endpoint,
not
the
execution
layer
but
just
providing
logs
for
who
is
that
for
the
data
basically
or
not?
And
with
this
it
was
like
rock
solid
as
well.
So
I
one
thing
that
I
probably
need
to
to
look
at.
C
I
didn't
ever
run
load
star,
like
as
a
as
a
consensus
player,
like
probably
yeah
I'll,
need
to
check
this
configuration
as
well
on
one
of
their
test
nets
to
see
how
it
behaves.
But
again,
lighthouse
was
also
quite
quite
okay,
but
just
you
have
that
much
things,
and
just
that
much
time.
So
it's
like
kind
of
we're
trying
to
manage
this
a
little
bit
in
a
in
a
way,
that's
still
very
useful,
but
yeah.
It's
not
that
easy
to
cover
everything.
A
B
We
so
we
didn't
have
easy,
quick
access
to
multiple
states
corresponding
to
multiple
blocks,
but
the
engine
and
in
the
proof
of
work
world.
It
worked
fine
because
you
you
occasionally,
you
can
do
a
re-work,
but
you
kind
of
to
do
that.
You,
the
real
yorks,
don't
happen
often,
and
you
don't
flip
flop,
typically
between
different
size
sign
chains.
So
you
can
so
you
can
still
operate
fine
with
the
single
state.
B
You,
okay,
which
you
occasionally
unwind
to
your
fork,
point
and
then
apply
changes
so
new
blocks
on
on
your
new
side
chain
and
how
the
engine
api
was
designed
originally
before
kiln.
Is
that
it
didn't
have
this
the
same
assumptions
as
the
proof
of
world
proof
of
work
world
and
it
could
send
more
requests.
It
assumed
that
you
you
can.
B
You
can
have
access
to
pretty
much
a
lot
of
states
corresponding
to
multiple
blocks
simultaneously,
which
wasn't
the
case
in
aragon
and
still
isn't
that
that
that
meant
that
we
were
not
able
to
implement
the
api
easily,
but
mikhail
kalinin
among
others,
have
regis
redesigned
the
engine
api
make
it
correspond
better
to
how
all
clients
operated
in
the
pro
work
world
and
specifically
to
make
it
suitable
for
aragon.
So
with
that
redesign
of
the
engine
api
we
we
implemented
it
and
joined
joint,
kiln
and
and
later
test
nets.
B
It's
still,
it's
still
not
fully
done
yet,
of
course,
and
I've
been
with
my
colleagues-
I've
been
looking
at
the
tests
in
hive,
so
you
might
have
heard
there
is
this
website
hive
test
two
dot
if
devops
dot
io,
which
runs
a
lot
of
tests
and
right
now,
aragorn
is
failing,
like
48
out
of
114
engine
api
tests,
so
we
are
working
on
bringing
that
number
down,
but
a
couple
of
weeks
ago
it
was
like
we
were
failing
80
right.
So
there
is
some
progress.
B
It's
it
still
takes
time
and
in
general,
more
testing.
So
we
yeah
we've
been
paying
more
attention
to
hive
tests
now
and
that
that's
very
helpful
that
ethereum
foundation
have
invested
into
into
this.
It's
kind
of
it's
still
not
for
me
as
as
as
a
developer,
it's
not
as
convenient
because
they
operate
via
docker
and
there
is
this
level
of
indirection.
So
it's
not
like
unit
tests
that
we
run
as
part
of
our
continuous
integration.
B
So
I
would
say
now
with
the
marriage
we
are
entering
this
like
the
the
basic
blocks.
The
fundamental
blocks
are
more
or
less
in
place.
We
might
still
do
some
architectural
improvements,
maybe
after
the
marriage,
but
right
now
we
are
focusing
more
on
testing
and
fixing
all
corner
cases,
things
and
improving
the
stability,
and
we
also
want
to
promote
at
some
point
our
alpha
to
to
beta
yeah.
But
it's
it's
such
things.
They
they
take
time
and
it's
it's
like.
B
C
Well,
one
more
story
for
for
me,
for
instance,
is
that
initially,
when
I
was
preparing
to
just
in
general,
supports
merch
like
the
first
validators
and
whatnot,
I
was
thinking
so
of
writing,
basically
both
processes
of
like
consensus,
layer
and
execution
layer
on
a
single
machine
somewhere
in
like
a
data
center
or
a
cloud,
but
it
turns
out.
That's
like
I
actually
started
tomorrow.
So
we
see
like
okay,
it
works,
it
works
it
works
and
then
it
starts
fading
at
the
stations
and
whatnot.
Then
you
restart
and
it
works.
It
works.
C
It
works
this
time.
It's
training,
manipulation
and
turns
out
that
like,
if
you
don't
have
physically
two
different
disks
at
least
disks
for
both
consensus
execution
layer,
both
like
with
everyone
and
maybe
with
other
as
well.
But
then
those
nodes
are
still
so
intensive
on,
like
this
kyo,
so
even
fast,
like
nbme
drives,
are
not
fast
enough,
so
the
nodes
are
slowly
getting
out
of
sync
like
so
they
are
not
fast
enough,
so
you
notice
them.
C
So
some
of
the
stations
are
fine
and
sometimes
coming
late
and
then
at
some
point
it
just
blows
up
completely.
So
that
was
a
video.
It
was
a
story
that
we
actually
either
needed.
Servers
was
two
separate
nvme
disks
completely
separate,
so
they
can
saturate
both
or
as
we
did.
We
just
split
them
into
two
different
machines
with
even
slower
just
normal
ssds,
and
it
was
fast
enough
to
work.
A
So
far,
it's
all
about
what
client
team
have
been
providing
to
users.
Now
I
have
a
question
for
you:
what
are
the
expectation
of
deaths
in
terms
of
support
that
they
can
expect
from
community
or
from
the
foundation?
Recently
we
heard
about
ef's
client
incentive
program.
Do
you
think
those
were
helpful
in
working
for
the
emerge.
C
Well,
I
can
talk
about
this
one
a
little
bit.
I
think.
That's
it.
It's
basically,
finally,
that
we
just
finished
like
we
just
entered
the
participation
fully
today.
Basically
so
today,
all
the
validators
went
online
for
the
aragon
literally
quite
today.
So
it's
it's
interesting.
I
think
it's
it's
a
good
program
in
terms
of
yeah,
because
when
you
run
your
own
nodes,
you
kind
of
don't
want
to
lose
this
stick.
So
again,
I
need
to
support
this,
but
I
think
it's
just
it.
C
You
know
it's
a
good
incentivization
to
just
fix
your
node
and
make
sure
that
it's
stable
long
run,
because
I
think
that
was
a
little
bit
of
a
disconnect
that
I
noticed
because
I'm
one
of
the
people
who
both
run
nodes
as
kind
of
professionally
and
also
develop
nodes.
There
was
a
little
bit
of
disconnect
between
people
who
built
nodes
and
who
run
those
again,
it's
getting
better
and
better
with
ethereum,
but
I
see,
for
instance,
other
blockchains.
C
B
C
One
thing
that
I
could
ask
the
community:
it's
just
a
genuine,
probably
it's
a
general
pain
of
like
of
the
open
source
developer
like
if
you
want
some
feature
or
if
you
want
some
feature,
changed
like
in
arizona.
We
had
this
with
health
checks
like
I
had
a
pet
peeve
of
mine,
like
I
developed
a
health
check
for
regular.
C
So
if
you
dislike
something
or
if
you
think
something
needs
to
be
added,
like
some
parameter
changed
or
something
like
this,
it
is
of
course
first
step
is
good
if
you
report
it
in
the
github,
but
then,
if
you
are
able
to
like
to
contribute
back
to
the
thing,
because
we
are
not
selling
carry
on
to
anybody
right,
so
it's
like
you
can
take
the
source
code
and
modify
it
and
run
it
and
actually
earn
money.
Doing
doing
that.
C
So
I
think
like,
if
you're
making
sure
that
okay,
your
pet
peeve
bug,
is
like
fixed
by
either
hiring
or
getting
some
engineer
who
fixes
it
or
like
fixing
like
contributing
back.
That
would
be
like
amazing,
that's
probably
the
best
thing
we
can
just
dream
of
so
but
of
course
like,
even
since
different
people
run
into
different
configurations,
just
decent
bug
requests
bug
reports
like
okay.
I
run
this
version
on
this
hardware.
C
I
did
that
and
that
that's
what
happened
would
be
also
very,
very
important
so
because
we
we're
trying
our
best
like
we're
doing
a
lot
of
things.
We
do
a
lot
of
testing
here
and
there
are
different
configurations,
but
still
you
might
have
some
esoteric
bug
that
we
will
never
be
able
to
even
know
about
because
we
never
run
it
on
a
certain
like
hardware
with
a
certain
limitations.
B
B
A
C
We're
trying
to
be
really
really
supportive,
like
especially
the
new
people
who
contribute
to
aragon,
trying
to
be
open
and
reasonable
with
code
reviews
and
whatnot.
So
don't
be
scared
as
well
like
we're
intimidated
by,
of
course,
the
complex
code
based
yada
yada,
but
like
we're
all
people,
and
we
all
just
just
normal
people
like
working
at
everyone.
So
we
are
very
open
to
like
suggestions
and
and
pull
requests.
B
And
I'd
like
to
add
that
people
who
maybe
who
are
interested
in
learning
more
about
the
execution
layer,
specifically
in
the
theorem
in
general
and
who
are
c
plus
plus
or
us
developers,
they
might
be
interested
in
silkworm
or
a
cooler,
because
their
code
bases
are
smaller
compared
to
aragon's
and
some
things
might
be
cleaner
and
it
might
be
a
good
learning
experience
in
terms
of
yoga.
He
won't
like
specifically
to
understand.
I
don't
know
how
recompiles
work
or
like
how
some
intro
cases
of
of
execution.
B
A
A
A
My
hope,
with
the
release
of
this
episode,
is
that
it
encourages
new
users
willing
to
join
ethereum
node
running
may
consider
aragon
for
execution
client
and
help
improve
the
stats
of
ethereum's
client
diversity,
and
on
this
note,
thanks
to
everyone
watching
or
listening
to
this
episode,
should
you
have
any
question.
Leave
a
comment.
Reach
us
at
ecatherist.com
check
out
descriptions
for
link
to
useful
resources
and
guest
twitter
to
follow.