►
From YouTube: PEEPanEIP#83: Teku and TheMerge with Adrian Sutton
Description
Topics covered
----------------------------
00:43 - About the client
01:26 - Guest introduction
2:32 - Presentation
2:46 - Teku team
3:25 - About Teku
4:28 - Flexible deployment
8:17 - REST APIs
10:44 - Preparing Teku for TheMerge
15:04 - The Path to the Merge
16:21 - March of Pandas
16:59 - Are Pandas too slow?
17:16 - The Merge and Late Blocks
17:58 - Timing is everything
21:18 - The Merge
23:24 - Questions
24:05 - Is it an invitation to the mainstream financial institutions or crypto exchanges and possibly ex-miners?
25:40 - Who are the main user base of Teku
28:23 - Is there any significant feature or spec difference in the client for institutional staking and solo staking?
31:00 - External key management for compatibility with enterprise-grade key stores
35:50 - Changes in Sync Committees duties since Altair upgrade
37:57 - Way to inform validators to protect from penalty
41:50 - Merge specific or Teku specific Metrics that the team is tracking
44:59 - Is there a dashboard or a proposed feature
46:29 - Do you think the issue of “not rendering emoticons correctly in graffiti” in Teku may have affected debugging at client level in any form?
49:24 - Implementation and advantage of EIP-4881: Deposit tree snapshot.
55:19 - Best EL client for Teku
58:16 - Thoughts on client diversity? How to increase network share?
1:01:33 - Message to Ethereum community
Resources:
-----------------
Slides - https://docs.google.com/presentation/d/1HY_J_7g2ivkQybUuIOSJ-vvRNnSv0beZ8heHSd6qprw/edit#slide=id.g8cb00373fc_0_96
TheMerge playlist - https://www.youtube.com/playlist?list=PL4cwHXAawZxqoLxXqZqT4hcYhoHoP6w12
KnowYourClient - https://www.youtube.com/playlist?list=PL4cwHXAawZxoruie1hmYWJfiakpYivXft
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
-----------------------------------------------
Adrian Sutton @ajsutton | Pooja Ranjan @poojaranjan19
Check out upcoming EIPs in Peep an EIP series at https://github.com/ethereum-cat-herde...
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...
Website: https://www.ethereumcatherders.com/
A
With
multiple
options
and
elcl
combinations
available
to
run
etm
nodes,
client
developers
are
inviting
participation
from
the
community
to
join
as
a
validator
and
contribute
to
the
game's
client
diversity.
Welcome
to
key
penny
episode,
83.
I
am
pooja
renton
on
this
special
episode
of
know.
Your
clients
series
we
are
joined
by
lead.
Blockchain
protocol
engineer
act,
consensus
adrian
sutton,
who
is
currently
working
on
development
of
teleco,
a
consensus
layer,
client
about
the
client,
as
per
the
official
website
description,
it
is
written
in
java.
A
Checo
is
equipped
to
bring
staking
services
to
businesses,
while
our
guest
adrian
has
been
on
our
show
earlier
to
talk
about
altair
upgrade
the
first
beacon
chain
upgrade
anyone
interested
to
follow.
The
earlier
talk
check
out
episode,
38..
We
will
learn
more
about
taiko
in
this
episode
with
adrian.
Thank
you
for
joining.
B
So
I'm
adrian
sutton,
as
budget
said,
I've
been
working
at
consensus
for
a
bit
over
four
years.
Now
my
initial
trial
by
fire
and
ethereum
was
helping
to
bring
baesu
to
its
first
release,
got
to
do
a
bunch
of
consensus
work
there
with
some
of
the
private
consensus
networks
ibft.
That
kind
of
thing,
then
into
the
core
of
the
evm,
a
lot
of
the
syncing
code.
B
That
kind
of
thing
and
for
the
past
three
years
or
so
I've
been
working
on
teku
and
again,
a
bit
of
a
trial
by
fire
got
dumped
in
bring
a
new
client
ready
to
version
one
and
we've
got
a
great
team.
That's
that's
helping
to
build
techy
there.
So
it's
been
a
lot
of
fun
and
really
really
exciting
to
see
the
journey
of
the
beacon
chain
through
from
launching
mainnet
a
while,
back
and
and
now
coming
up
to
the
merge.
A
B
Right
so
today
I
want
to
take
you
through
some
of
the
work
that
we've
done
on
techyu
in
getting
to
the
merge
how
that
works
and
just
a
couple
of
interesting
details,
and
then
we
hopefully
have
some
time
for
some
questions
that
you
might
throw
at
me
as
well.
We
already
talked
about
me
a
bit
so
I'll
skip
through
that,
but
I
mentioned
we
have
a
great
team
behind
teku
and
that's
grown
a
bit
since
last.
I
was
here
which
is
fantastic,
so
those
people
there
are
the
core
development
team.
B
There
is
a
whole
host
of
people
behind
the
scenes
at
consensus
that
help
get
things
done,
plus
an
increasing
number
of
external
contributors,
which
is
fantastic.
We
love
having
people
raise
issues
in
github,
bring
up
prs,
we're
happy
to
work
with
people
to
explain
where
a
change
might
need
to
be
made
or
how
the
code
works,
and
things
like
that
get
get
you
going
on
developing
tech,
so
always
very
welcome
to
jump
in
and
be
part
of
a
team
as
well.
B
What
is
teku,
what's
what's
its
point
in
in
existing?
Well,
we've
kind
of
carved
out
the
niche.
A
little
bit
of
being
a
bit
more
enterprise
focused
so
we're
a
full
consensus
layer.
Client.
We
fully
support
the
beacon
chain,
standardized
fully
interoperable
anyone
can
use
it.
It's
performant,
it
does
all
the
right
things.
It
is
apache
2
license,
which
is
quite
nice,
that
a
lot
of
our
beacon
chain,
clients
are
apache.
2
gives
a
bit
more
flexibility,
it's
less
scary
for
enterprise
customers
and
things
like
that.
B
B
So
we
talked
about
being
enterprise
focused
a
lot
of
that
is
about
flexibility
and
I'll
get
into
that.
It
doesn't
mean
that
homestakers
can't
use
toku
or
shouldn't
use
tekku.
We
actually
have
done
a
lot
of
work
to
really
scale
from
being
really
simple,
to
use
in
simple
cases
and
have
the
flexibility
for
more
complex
things.
So
you
know
talking
about
that.
One
example
is
how
you
can
deploy
deco,
actually
has
a
simpler
deployment
model
than
a
lot
of
clients,
in
that
we
can
run
the
beacon,
node
and
validated
client
together.
B
So
one
command
and
you
can
have
your
entire
node
and
validator
up
and
running.
Nimbus
has
the
same
thing,
whereas
prism
and
lighthouse
have
two
separate
commands
that
you
run
and
you
need
to
run
them
separately
and
have
the
http
interface
connecting
between
them,
and
I
must
admit,
I
forget
whether
lowstar
has
the
combined
mode
or
separator.
B
So
that's
great
for
a
really
simple
setup
and
it
keeps
things
nice
and
easy
for
you.
But
tech
also
supports
running
the
validated
client
separately.
So
if
you
want
to
have
it
on
a
different
machine
for
some
reason
or
in
different
network
topologies,
you
can
do
that
and
then
we've
supported
web3signer
since
the
start
of
the
beacon
chain
as
well
for
an
external
signup.
So
you
can
have
your
keys
stored
in
a
hardware
security
model
and
that's
kind
of
becomes
a
much
more
nested
layers
of
security.
B
As
you
get
these
complex
outs
and
then
within
that,
there's
ability
to
do
failover
in
different
ways
and
manage
keys
and
so
on.
So
once
you
get
up
to
a
staking
service
type
of
environment,
it
can
be
really
powerful
to
have
that
flexibility,
but,
as
I
was
saying,
no
reason
that
that
flexibility
has
to
make
life
more
difficult
for
a
homestaking
user.
You
can
just
use
a
simple
thing
and
you
can
mix
and
match
all
of
these
things.
B
One
of
the
big
things
that
we
try
and
do
with
tecu
is
really
put
the
user
in
control.
So
there's
a
lot
of
flexibility
about
storage
locations.
Again,
most
people
just
say:
here's
my
data
path.
This
is
where
you
should
store
all
your
stuff,
but
you
can
tell
us
this
is
where
the
beacon
node
data
goes.
This
is
the
validated
client
data
separately.
B
We
make
a
real
point
of
not
needing
you
to
import
keys.
You
just
tell
us
where
your
keys
are
your
your
key
stores
are
and
we
can
load
them
from
there.
So
that
gives
you
the
flexibility
to
store
them
somewhere
different
to
the
beacon
chain
or
the
slashing
data
you
can
store
them
on
a
you
know,
usb
stick.
B
So
it's
easy
to
to
have
that
as
a
hardware
encrypted
type
usb
things
like
that
usb
stick
is
probably
not
the
most
common
location
for
them,
not
really
strongly
recommended,
but
certainly
in
terms
of
managing
backups
and
things
like
that
being
in
control
of
where
things
live.
It
makes
a
lot
easier
and
it
means
that
you're
not
creating
a
copy
of
the
key
as
you
import
them
either.
So
you've
clearly
got
key
in
just
one
place,
which
is
really
important
for
not
getting
yourself
slashed,
obviously
other
clients
import
them
delete.
B
The
original
is
generally
a
good
policy
and
the
same
with
logging.
So
out
of
the
box,
tecu
has
nice
clean
login
to
the
console
with
more
detail
to
a
log
file,
but
you
can
control
that
you
can
send
it
all
to
the
console.
You
can
send
it
all
to
local
and
all
the
way
up
to
the
point
where
you
can
basically
take
over
complete
control
of
logging.
It's
not
just
a
matter
of
saying
you
know.
I
want
level
one
two,
three,
four
five
debug
info
type
level
of
logging.
B
You
can
give
us
a
custom
configuration
file
for
logging
and
say
that
I
want
info
logs
going
to
the
console.
I
want
debug
logs
for
this
particular
module
going
to
this
file.
I
want
logs
for
that
module
going
to
this
other
file.
I
want
trace
of
http
interactions
with
the
execution
client
going
to
another
file.
All
of
those
things
are
quite
possible
with
the
logging
setup
again
home.
Staker
you're-
probably
never
going
to
use
that,
but
that
flexibility
is
there
and
can
be
really
powerful
for
investigating.
B
What's
going
on
and
seeing
how
things
are
working
in
a
more
complex
setup,
the
other
area
that
teku
has
kind
of
found
a
bit
of
a
niche
in
is
our
support
for
the
rest
apis.
Now
all
the
clients
support
standard
rest,
apis
and
attackers
are
the
same.
We've
got
a
few
custom
ones
like
most
clients
do,
but
generally
it's
the
standard
rest
apis.
People
use
and
tecuo's
is
behind
infurer's
beacon,
chain
service.
B
So,
when
you're
connecting
to
the
appearance,
these
two
endpoints,
that's
actually
techy
nodes
that
are
powering
those
responses
and
when
you
start
handling
that
kind
of
load
you
start
to
to
want
some
custom,
specially
designed,
storage
and
so
on.
To
help
do
it
and
one
of
the
things
we've
got
for
that
is
this
merkle
tree
based
storage?
It's
an
optional
thing:
you
don't
need
to
use
it,
and
it
has
this
trade-off
that
it
will
use
a
crap-ton
of
this
space,
so
it
stores
absolutely
every
state
it
can
de-duplicate
across
states.
B
So
it's
more
efficient
than
using
a
snapshot
based
approach
to
states
and
storing
every
slot,
but
it
is
big
what
it
gets.
You,
though,
is
really
fast
access
to
finalize
state
data.
So
if
you're
asking
for
the
balance
of
a
validator
at
some
old
slot,
maybe
you're
doing
your
tax
history
and
you
want
to
see
where
your
validator
is
at.
We
don't
even
need
to
load
the
full
state
off
of
this.
B
B
In
terms
of
when
things
are
finalized,
we
don't
need
to
move
them
into
the
finalized
state
storage.
So
it's
really
effective
for
validating,
because
there's
no
reason
you
need
those
old
states
right.
Let's
talk
the
merge
the
journey
to
the
pandas,
so,
firstly,
to
cover
the
the
kind
of
mechanics
for
a
user.
What
do
you
need
to
do
to
get
techy
ready
for
the
merge?
So
the
first
thing
is
to
say
is
probably
that
you
should
wait
until
the
merge
is
scheduled
for
the
network
you're
on.
So
currently,
all
the
test
nets
have.
B
The
merge
scheduled
mainnet
doesn't
yet
so
hold
off
on
mainnet
for
this
just
yet,
but
for
for
the
test
nets.
Now
is
it's
a
pretty
good
time
to
be
doing
that
for
some
of
them
they've
already
merged
and
you'll
need
it
for
prada
and
goalie
that
merges
scheduled
and
coming
soon
and
in
mainnet,
hopefully
not
too
far
away?
We
will
have
that
scheduled
and
you'll
go
through
this
process
as
well,
and
there's
really
three
things
to
do.
B
The
first
is
to
switch
to
using
the
engine
api
to
talk
to
the
execution
client,
which
switches
from
port
8545
by
default,
that
normal
json,
rpc,
port,
you'd
use
with
metamask
and
all
kinds
of
other
things
to
a
dedicated
port
for
consensus
layers
to
talk
to
the
execution
layout
by
default
port
8551,
and
that
port
allows
control
of
the
execution
client.
It's
not
just
sending
transactions
or
querying
data.
It's
actually
telling
it.
What
the
canonical
chain
is.
B
So
it's
a
little
bit
more
important
and
for
that
the
execution
client
will
require
jwt
authentication
and
that's
just
a
file
with
32-bit
random
data
in
it
that
we
can
then
use.
So
you
want
that
same
file
shared
between
the
execution,
client
and
the
consensus
client.
You
specify
that
with
the
eew
jwt
secret
file
option,
we've
got
clear
docs
on
this,
so
so
I
won't
try
and
recite
all
the
endpoints
and
we
move
from
the
eth1
endpoint
to
the
ee
endpoint.
B
The
other
big
catch
in
moving
to
the
merge
is
because
the
beacon
node
is
now
controlling
the
execution,
client
and
actually
doing
right
updates
to
it.
Instead
of
just
querying,
we
really
move
to
a
one-to-one
pairing
of
beacon,
node
execution
client.
So
where
previously,
you
might
have
had
inferior
as
a
fallback
that
won't
work
post,
merge,
inferior,
won't
expose
an
engine
api
and
it
doesn't
scale
in
that
way.
B
B
So
you'll
want
to
update
to
the
version
that
is
announced
for
whichever
network
you're
on
that
has
that
merge
configuration
built
in,
but
particularly
coming
up
to
that
point
of
the
merge
just
after
watch
for
updates.
If
we
find
last
minute
issues
or
a
change
in
in
the
configuration
is
required
because
estimating
when
things
are
going
to
merge
is
fairly
difficult
based
on
the
total
difficulty,
we
may
need
to
tweak
that
fairly
last
minute,
so
keep
an
eye
on
the
update
channels.
B
So
most
people
keep
using
this
one.
That's
where
the
value
is
on
proof
of
work
and
we've
got
to
test
one
on.
That's
that's
merged
we're
seeing
things
work
at
scale
then
so
we're
actually
a
really
long
way
along
this
we're
right
up
towards
we're
already
forking
test
nets
and
the
kind
of
the
march
of
the
pandas
is
is
moving
on
really
well.
B
B
B
B
B
We
then
need
to
process
the
block
to
create
the
post
state,
so
apply
it.
Then
we've
got
to
send
it
out
to
the
network.
That's
got
to
gossip
across
all
the
nodes.
Each
of
them
have
to
import
it,
which
means
doing
all
the
beacon
chain,
validation
and
processing,
but
also
sending
that
to
the
execution
layer
which
has
to
process
it
as
well
and
then
finally,
they've
got
to
produce
their
attestation.
B
Adding
in
those
extra
couple
of
things
with
the
execution
layer
is
a
pretty
big
concern,
particularly
because
it's
a
http
request
away,
it's
kind
of
the
latency
even
of
that,
what
we've
done
is
cheated,
which
is
really
cool.
So
when
we're
producing
attestations
for
one
slot,
we're
actually
telling
the
execution
layer
to
prepare
for
the
next
slot
already,
so
it's
getting
about
eight
seconds,
sometimes
less.
If
a
block
is
late
or
things
like
that
or
we
re-org
after
this
point.
B
B
B
While
we
apply
the
beacon
chain
validations
and
doing
all
the
work
of
that,
and
then
we
get
a
response
back
from
the
execution
layer
saying
it
was
valid
or
invalid
and
we
can
go
on
and
finish
and
the
same
when
we're
creating
a
block
when
we
actually
request
the
payload
at
the
same
time
as
the
execution
layer
is
getting
that
back
for
us
we're
creating
our
stations.
So
all
of
this
extra
time
happens
in
parallel.
We
use
a
little
extra
cpu.
B
So
if
you
were
really
tight
on
cpu
before
you
might
notice
that,
but
generally
that
there's
those
resources
are
available
and
we
can
do
it
in
parallel
and
everything
has
worked
out
really
well.
So
it's
been
one
of
the
really
exciting
things
for
me,
seeing
this
consistently
across
test
nets
and
the
shadow
forks
even
at
scale
that
we're
not
seeing
a
slowdown
in
producing
blocks
and
that's
one
of
the
big
hurdles
that
we
needed
to
solve
for
the
merge
and
turns
out.
B
So
are
we
ready
to
ship
the
merch?
It's
a
big
question,
a
million
dollar
question.
Well,
we
talked
about
this
a
little
earlier
that
the
only
domino
left
to
fall
is
mainnet,
so
we're
going
to
see
we're
going
to
see
prada
and
glory
merge,
that's
quite
big
in
terms
of
what
the
community
has
to
do.
This
is
the
first
time
we've
taken
a
network.
That's
got
not
a
majority
of
community,
but
a
large
part
of
it.
B
It's
it's
up
towards
the
30
percent
of
a
ballad
is
a
run
outside
of
the
core
dev
control.
We
we
run
a
lot,
try
and
keep
it
nice
and
stable
as
people
come
and
go,
but
this
is
where
the
community
will
need
to
step
up
and
show
that
they
can
configure
things
that
our
documentation
is,
is
good
enough
and
those
kinds
of
things
that
people
are
ready
to
go
through
that,
because
on
mainnet
the
letters
are
very
distributed.
The
core
devs
run
very
very
few.
B
I
I'd
be
very
surprised
that
we
have
even
one
percent
of
the
battle
letters
between
us
on
mainnet
and
and
it's
really
going
to
be
up
to
staking
services.
Solo
stakers
think
people
like
that.
Are
they
ready?
That's
the
big
thing
we
want
to
see
in
goalie,
but
to
me
I
think,
we've
seen
quite
consistently
through
the
shadow,
forks
and
the
test
nets.
This
stuff
is
working.
B
We're
really
seeing
a
lot
of
reliability
in
how
the
network
functions
we're
seeing
how
it
recovers
well
from
misconfigurations
or
other
problems
that
cause
cause
some
turbulence
and
lots
of
corner
cases
are
being
hit
there.
So
for
me
I
say
we
take
this
panda
to
the
moment.
I
think
we're,
I
think,
we're
ready-
and
I
think
that's
that's-
really
cool
and
really
exciting.
We're
going
to
do
it
sensibly.
There's
always
you
know,
no
developer
will
say
we're
ready
without
any
caveat
mine
is
if
something
unexpected
pops
up
course,
we'll
delay.
B
A
Think
you
pretty
much
covered
everything
I
mean
like.
I
really
love
the
journey
to
the
pandas.
It
was
a
great
presentation.
Thank
you.
I
have
got
a
few
questions
that
we
have
already
collected.
First
of
all,
thank
you
for
answering
my
biggest
question
that
it
is
not
only
for
institutional
staking
but
also
like
homestakers
can
also
make
use
of
that.
That
is
really
good
to
know
so.
B
But
we've
also
got
a
long
track
record
of
consensus
of
working
with
some
of
the
bigger
banks
and
institutional
players
from
outside
of
crypto
and
helping
bring
them
into
the
crypto
world,
and
I
think
that's
an
important
thing
and
something
that
that
we
want
teku
and
besu
both
to
continue
doing,
because
when,
when
ethereum
is
kind
of
completely
separate
from
the
traditional
finance
world,
it's
going
to
be
ignored.
It's
not
going
to
reach
its
full
potential.
B
I
don't
think
we
want
to
become
the
traditional
finance
world,
but
I'm
quite
happy
for
the
traditional
finance
world
to
come
over
and
join
us
in
the
decentralized
world,
and
I
think
we
want
to
build
tools
and
systems
that
they
can
be
comfortable
with.
So
things
like
using
java
is
very
helpful
for
them,
but
also
just
you
know,
consensus
has
a
big
company
behind
it
with
support
contracts,
and
things
like
that.
So
we
can
provide,
and
just
a
way
of
working
and
understanding
that
the
institutional
players
that
might
be
outside
of
crypto
can
understand.
B
B
B
This
way
with
that
way
or
new
ideas
and
so
mikhail's
work
on
the
merge
is
a
really
great
example
of
that
he's
on
one
of
our
research
teams
and
was
able
to
pick
up
teku
and
say
well.
What,
if
we
didn't,
do
the
merge
that
we
all
originally
thought
we'd
have
of
you
know
this
much
bigger
model
of
emerge.
What
would
minimal
work
look
like
and
he
started
prototyping
it
that's.
B
B
B
In
terms
of
things
to
add
things
like
automatic
failover
for
our
separate
battle,
led
client
to
multiple
beacon
nodes,
that's
in
progress
now,
so
that's
a
pretty
big
deal,
particularly
post
merge.
I'm
not
sure
ben
keeps
surprising
me
with
ideas
that
he
has
so
there's.
I
think,
there's
a
bunch
we
can
do
actually
around
there's
been
some
talk
of
having
a
sentry
node
for
sending
block
proposals
to
we'll
do
that.
I
think
there's
a
lot
of
options
around
being
able
to
configure
what
a
validated
client
uses
from
a
set
of
beacon
nodes.
B
So
at
the
moment
we
usually
talk
about
failover.
I
think
we
can
go
a
lot
further
with
that
in
terms
of
saying,
because
we
have
these
64
subnets
for
attestations
and
if,
if
you've
got
64
clients
or
more
you'll
subscribe
to
all
of
them,
so
what
winds
up
happening
in
most
staking
services?
They
run
a
lot
of
beacon
nodes
that
are
actually
trying
to
keep
up
with
every
attestation,
which
is
quite
expensive.
B
There's
a
lot
of
efficiency
that
I
think
we
can
gain
in
that
kind
of
model
and
and
potentially,
and
so
that's
one
of
the
things
that
I'm
interested
in
getting
into
but
yeah.
I
don't
always
get
a
say
in
what
we
do.
That's
that's
ben's
job,
there's,
there's
always
new
and
exciting
things.
You
know
obviously
there'll
be
a
lot
of
work
going
into
things
like
withdrawals
and
the
future
hard
forks
as
well,
and
we'll
continue
to
to
do
a
lot
of
optimizations.
B
A
Absolutely
I
think
I
will
I
have
some
questions
related
to
what's
new
and
different,
and
this
one
will
come
there,
but
first
I
would
like
to
talk
about
the
out
of
the
box
features
that
you
mentioned,
that
anyone
running
taco
node
are
getting
like.
One
of
those
features
are
key
management
right,
so
I
understand
like
in
blockchain.
Key
management
is
generally
an
important
concept
and
with
pos
it's
like
validated
key
or
the
to
key,
they
are
needed
to
do
some
activities
like
attestation
and
drug
proposals.
A
B
Right
so
most
of
that
is
through
the
web3
signup
product
which
tecu
supports,
and
so
it's
this
idea
of
using
an
external
signup.
So
what
does
that
give
you?
Well?
The
first
thing
is
that
you
are
able
to
set
up
your
network
so
that
your
validator
client
can
connect
to
your
external
signup,
but
the
external
signer
doesn't
need
any
internet
access.
B
It
can
be
completely
firewalled
off,
except
for
that
box,
and
your
validator
client
only
needs
to
talk
to
your
beacon
nodes,
so
it
can
be
firewalled
off
from
the
internet
and
only
talk
to
that
box.
So
now,
there's
kind
of
three
layers
of
firewalls
you've
got
to
get
to
before
you
can
get
anywhere
near
your
keys.
That
in
itself
is
is
powerful.
B
B
So,
if
you're,
finding
that
one
validated
client
is
on
hardware,
that's
died
or
it's
struggling
for
whatever
reason
you
can
move
those
keys
to
another
battle.
Data
client
with
much
much
less
slashing
risk
or
basically
no
slashing
risk,
because
you
know
that
you're
not
actually
moving
the
keys
and
you're
not
changing
the
way
slashing
protection
is
done.
That's
all
still
in
the
word
three
signer
layer-
and
this
is
a
much
safer
operation
to
move
around
then
that
kind
of
flexibility
is
really
really
powerful
for
large
staking
setups.
A
B
Yeah-
and
I
think
that's
one
of
the
interesting
things
that
I
didn't
see
coming
is
I
forget
which
system
it
is,
but
there's
there's
one
it
might
have,
might
even
be
dap
node.
I
think
that
wound
up
using
web3
signer
to
hold
these
now,
it's
targeted
at
home
users,
but
they
wanted
to
make
it
easy
to
switch
clients.
B
So
all
the
keys
went
into
edit
resigner
and
now
they
don't
have
to
migrate
keys
that
same
select,
slashing
protection
safety.
You
can
easily
spin
up
and
down
any
validated
client
and
beacon,
node
combination.
You
want
without
moving
keys
around
and
that's
that's
actually
a
really
cool
use
case.
It's
it's
designed
for
home
users.
There
might
only
be
one
key
involved,
but
moving
keys
is
scary
and
anywhere
you're
touching
your
slashing
protection
records
is
really
scary,
so
if
you
can
leave
them
in
place
and
change
things
in
front
of
them,
it
works
really
well.
A
B
Yeah
yeah
there's
some
there's
new
stuff
added
to
all
clients.
I
think
around
the
key
management
apis
as
well,
so
you
can
it's
being
used
by
a
lot
of
user
interfaces,
so
we're
going
to
get
a
custom,
a
single
user
interface.
We
can
work
with
multiple
nodes,
which
is
great,
and
turkey
fully
supports
that.
So
you
can
add
and
remove
keys
that
way
and-
and
that
includes
importing
and
getting
your
slashing
protection
back.
So
that
makes
a
lot
of
things
easier
as
well.
A
I
understand
sync
committee
duties:
we
did
talk
about
it
at
the
time
of
altair
and
as
per
my
understanding,
it
is
basically
a
group
of
validators
which
are
randomly
assigned
to
signing
of
blogs
for
newsletters.
I
wonder
if
there
are
any
changes
of
duty,
since
they
are
there
upgrade
and
when
we
are
getting
into
the
merge.
B
B
I
guess
the
only
slight
wrinkle
we
have
with
the
merge
that
affects
things
slightly.
Is
you
need
the
execution
client
to
be
able
to
fully
validate
a
block?
So
if
your
execution
client
is
down
today,
pre-merge
you
can
keep
the
testing
most
of
the
time.
You
can
create
a
block.
It's
only
if
you
need
to
include
deposits
that
you
might
fail
to
produce
that
block
post
merge.
If
your
execution
client
is
down,
you
will
not
be
able
to
to
a
test
or
your
sync
committee
duties
will
stop.
B
Basically,
all
your
validated
duties
stop,
because
you
haven't
validated
those
blocks
and
it
wouldn't
be
safe
to
attest
to
them
so
yeah.
You
will
see
that
generally
clients
in
tekku
included
implement
optimistic
sync,
so
we're
able
to
follow
the
beacon
chain.
Even
while
the
execution
client
is
still
syncing,
it
has
to
be
online.
It
has
to
be
able
to
tell
us.
B
Yes,
I
checked
the
basics,
like
the
block
hash
matches,
what
I
said
it
should
be
and
a
couple
of
other
checks
that
need
to
be
done
for
every
block,
but
it
doesn't
necessarily
have
to
have
a
whole
world
state
and
ability
to
execute
that
block,
and
so
we'll
be
able
to
tell
you.
You
know
where
we're
up
to
in
the
chain
and
see
the
chain
head
and
that
helps
the
execution
client
sing.
But
even
then
we
won't
be
performing
those
duties.
B
So
it's
like
an
attestation
that
has
to
be
100
perfect
every
time
or
it
doesn't
get
included
at
all
a
lot
of
that
which
means
that
if
there
is
a
late
block
that
comes
in
after
the
four
second
mark,
you
will
produce
a
sync
committee
message
saying
that
slot
was
empty
in
reality.
That
block
will
come
in
and
and
be
filled.
B
So
that
makes
your
sync
mini
message
wrong
and
it
won't
be
included
if
you
have
an
empty
slot
after
you
produce
the
sync
committee
message.
Your
sync
committee
message
just
can't
be
included
because
there's
no
block
to
include
in-
and
it's
not
valid
the
next
slot.
So
it's
common
and
normal
to
miss
sync
committee
messages
and
not
have
them
all
included
generally.
80
is
probably
pretty
good,
probably
more
90
on
main
net
I've
been
looking
at
prada
and
goalie
a
lot
lately.
So
I
might
be
on
might
be
low
balling.
B
Those
figures,
a
little
probably
is
higher
than
that
on
mainnet,
but
you
know
not
uncommon
to
see
things
that
are
see.
Sync
committee
messages
not
be
included
and
get
a
small
penalty
for
that,
but
you
know
as
long
as
you're,
including
at
least
50
you're,
going
to
make
money.
It's
the
same
thing
as
attestations.
You
lose
about
what
you
would
have
gained
so
if
you're
up
in
that
90
range
you're
making
plenty
of
money.
So
it
isn't.
B
As
simple
as
saying
I
missed
one
sync
committee
message:
I
should
raise
the
alarm
and
panic,
or
even
two
or
three
in
a
row
may
net
two
or
three
in
a
row.
You
probably
should
panic
prior,
that's
normal,
so
yes,
there's
probably
more,
we
could
do.
I
think
some
of
that
is
metrics
that
that
exist
and
we
you
can
set
up
alerting
through
prometheus
grafana.
That
kind
of
thing
some
of
it
will
be
things
like
beacon,
chain
app,
which
already
provides
alerts.
B
When
you
miss
out
of
stations,
you
can
provide
more
information
through
sync
committees.
I
think
it
does
provide
notifications
when
you're
in
the
sync
committee
now
might
have
that
wrong,
but
those
kind
of
tools
are
definitely
worth
having
and
keeping
you
informed
about
your
validator.
You
know
you're
in
a
sync
committee.
You
generally
have
about
a
day's
notice
and
you're
in
the
committee
for
about
a
day.
So
if
you
know
it's
coming,
then
it's
a
day
that
you
don't
do
upgrades
and
things
like
that,
and
that
certainly
makes
a
lot
of
sense.
Yeah.
A
B
A
A
B
Yeah,
there's
probably
a
couple
of
things:
the
first
one
that
I
try
and
watch.
I
mostly
do
it
through
the
logs.
To
be
honest,
is
what
gas
usage
is
in
the
blocks
we
produce.
So
there
have
been
some
problems
with
different
execution
layer,
clients,
not
including
transactions,
and
if
you
don't
give
the
execution
layer
enough
time
because
blocks
later
things
like
that,
then
you
do
tend
to
get
an
empty
payload
back
with
no
transactions
and
then
you're
missing
out
on
inclusion
fees.
B
B
That
will
vary
a
lot
on
test
nets
because
there
aren't
always
transactions
to
include,
but
on
mainnet
generally
should
be
about
that
50
value,
and
I
think
we
have
metrics
for
that
as
well,
which
I
should
add
to
my
normal
dashboard.
So
I
watch
it
that
way
more
and
make
my
life
easier,
but
that's
really
useful
to
see.
Am
I
getting
transactions
included?
B
Those
are
worth
tracking
and
there's
also
a
a
bunch
of
block
timing,
so
particularly
for
institutional,
where
you're
running
a
lot
of
nodes-
and
you
want
to
correlate
it
together
being
able
to
see
how
long
it's
taking
to
create
the
blocks
that
you're
producing
at
a
high
level
is
really
useful.
So
we've
got
some
metrics
that
can
be
enabled
for
that
as
well.
The
same
thing
will
happen,
works
for
average
station
timing.
B
You
can
see
you
know
which
bucket
falls
in
whether
it
was
you
know
nearly
instant,
soon,
starting
to
get
quite
late,
that
kind
of
thing,
and
also
even
for
block
arrivals
and
block
processing.
So
there's
there's
a
bunch
of
that
timing.
Metrics.
That
detectives
can
provide
to
give
you
insight
into
what
the
network
is
doing
to
you.
Are
you
receiving
blocks
late
because
your
peers
are
bad
or
because
the
network
is
just
struggling?
Are
you
processing
them
slowly?
What
parts
are
going
wrong
there
and
then
are
you
performing
your
duties
in
a
timely
manner?.
B
B
B
You
know
help
you
create
the
custom
dashboard,
that
kind
of
works
for
what
you're
actually
trying
to
do,
because
there
is
a
ton
of
flexibility
and
a
ton
of
metrics
and
the
way
that
I
like
seeing
things
is
often
different
to
the
way
someone
else
wants
to
see
them
or
needs
to,
and-
and
I
think
that's
that's
good
right-
you-
you
want
to
use
the
flexibility
of
grafana
to
come
up
with
the
dashboard
that
works
for
your
particular
setup.
Not
just
take
something.
That's
entirely
off
the
shelf.
All
the
time.
A
Absolutely
I
mean
I
must
congratulate
all
the
client
developers
here
that
they
are
taking
every
question
on
this
card
for
every
user
like
if
you
are
facing
any
challenge,
please
reach
out
to
respective
discord.
They
are
there
to
help
and
we
are
doing
everything
to
encourage
a
potential
user
to
become
a
validator
of
ethereum
network.
That's
awesome,
one
thing
about
tracking
issues
or
some.
If
something
goes
wrong,
it
is
specially
about
graffiti
earlier.
B
No
so
emoticons
in
graffiti
are
not
particularly
useful
for,
for
debugging.
Usually
a
custom
graffiti
is
is
actually
moving
away
from
something
that's
more
useful
in
that
the
default
is
generally
to
have
the
actual
consensus.
Client
version
in
the
graffiti.
That
particular
issue
was
an
interesting
one,
because
tecu
itself
had
no
issues
and,
in
theory,
was
kind
of
doing
the
right
thing.
B
What
it
was
was
that
it
was
being
configured
with
the
unicode,
an
emoji
as
a
unicode
character
in
a
string,
and
they
were
running
in
docker
now,
docker
resets,
all
the
environment
variables.
It
gives
you
a
nice
clean
slate
and
our
techyou
image
respected
that
and
just
left
it,
which
meant
that
it
actually
dropped
back
to
using
us
ascii
as
the
basic
c
locale.
B
So
when
you
take
unicode
string,
run
it
through
us
gasket,
you
get
a
couple
of
question
marks
instead
and
particular
would
correctly
render
a
couple
of
question
marks,
which
you
know,
isn't
very
user
friendly
and
helpful.
So
we've
now
set
up
the
docker
image
to
default
to
unicode,
but
that
was
just
a
configuration
issue
in
terms
of
why
the
emoji
didn't
turn
up
and
you
get
some
fun
things
like
that
with
docker.
Sometimes
it's
it's
brilliantly
repeatable,
but
sometimes
it
will
repeat
exactly
what
you
didn't
want.
A
B
Absolutely
yeah,
I
I
was
talking
to
one
of
the
people
from
marketing
at
consensus
a
while
back
and
it
was
the
last
devcon
and
she
was
new
to
the
blockchain
environment
and
come
on
board.
She
said
you
know
thing.
I've
learned
is
that
all
of
that
that
stuff
you
know
of
just
throwing
glitter
and
unicorns
and
things
that
is
just
completely
over
the
top
and
that
you
would
never
get
any
traction
with
anywhere
else.
Just
do
it
here,
like
that's
what
we
go
for
at
least
it's
this
kind
of
almost
crazy
community.
B
A
Absolutely
I
have
one
more
question
on
one
of
the
topics
that
you
briefly
touched.
It
was
about
the
depository
snapshot,
the
implementation
of
vip
4881.
I
guess
so
mark
the
author
of
the
proposal
briefly
talked
about
this
proposal.
In
the
last
talk
with
the
lighthouse,
I
was
wondering
if
there
is
any
client
implementation
but
found
that
the
recent
release
of
deco
suggests
that
there
is
the
progress
on
on
implementing
this
proposal.
So
can
you
maybe
briefly
talk
about
the
advantage
of
this
depository
snapshot?.
B
B
So
the
idea
of
this
snapshot
is
that
when
we
finalize
the
beacon
chain,
there
is
a
whole
section
of
the
merkle
tree
that
we
can
basically
shave
off
and
just
keep
the
right
edge
of
its
hashes,
which
is
a
lot
less
to
saw
we're
not
now
storing
a
hash
for
every
deposit,
which
is
great
slightly
slightly
less
memory.
It's
not
a
big
use
of
memory
anyway,
but
we've
got
that
working
now
in
techyou
this,
the
merkle
tree
structure
we're
using
internally
does
that
pruning,
and
so
it's
slightly
more
memory
efficient.
B
So
rather
than
scanning
every
deposit,
we
can
load
one
of
these
snapshots
and
then
we're
up
to
date,
basically
very
quickly,
very
similar
to
checkpoint
sync,
where
you
give
an
initial
state
and
it's
a
beacon
state.
This
kind
of
checkpoint
sync
for
your
deposit,
merkle
tree,
and
so
I
think
in
the
future.
B
The
idea
will
be
that
you
get
an
initial
state,
which
is
this
beacon
state,
along
with
a
checkpoint,
a
snapshot
of
your
deposit,
merkle
tree,
and
that's
everything
you
need
to
get
started,
which
is
which
is
really
nice
and
gets
things
up
and
running,
and
then
the
ip44s
can
come
through.
We
can
prune
more
stuff
from
the
execution,
client
and
store
less
data
on
disk
as
a
total
ethereum
node.
B
B
A
B
There's
a
lot
going
on
yeah,
it's
it's
great
to
have
built
up
a
good
team
and
there
is
a
really
great
team
behind
teku.
I
tend
to
turn
up
on
discord
a
lot,
because
that's
that's
what
I
like
doing,
I
like
being
being
in
in
the
community
a
bit,
but
you
know
those
those
people
I
had
on
the
slide
before
a
lot
of
them.
B
You
don't
see
as
much
but
they're
doing
some
absolutely
fantastic
work
in
the
background
and
they're
still
more
before
them
that
that
have
been
on
turkey
team
and
moved
on
in
various
ways.
We
have
a
terrible
habit
of
losing
people
to
be
fancy
ctos
of
d5
startups,
and
things
like
that.
So
you
know
great
way
to
create
a
career
starting
injector.
B
Obviously
come
join
and
work
for
us,
but
yeah
that
that
team
that
team,
that
we
have
there,
I
think,
is
one
of
the
keys
to
success
and
that
we've
we've
invested
really
hard
in
hiring
the
right
people
and
training
them
up
and
doing
that
and
a
lot
of
the
people,
particularly
inbase
who've,
come
from
outside
of
blockchain
again.
So
that's
something!
I'm
really
proud
of
that
we're
bringing
people
into
the
ethereum
space,
not
just
kind
of
head
hunting
for
people
who
are
already
doing
something
else
in
the
in
the
environment.
A
All
right,
I
know
we
are
very
close
to
time.
I
have
couple
of
more
questions
to
go.
One
is
related
to
the
merged
test
nets
like
I'm,
assuming
that
sekou
must
have
been
participating
in
all
the
test
nets
that
that
were
there,
like
all
devnet
zero
to
five
shadow
working,
mainnet
and
public
testing,
would
there
be,
in
your
mind,
be
the
best
client
combination
for
teku?
I
know
besu
is
a
part
of
it.
I
like
bazel,
also
in
java,
and
this
also,
but
what
would
you
consider.
B
I
don't
think
it
matters.
I
think
I
think
it's
one
of
these
cases
where
every
consensus
client
works
just
as
well
with
every
other
execution
layer,
client
and
where
you
see
differences
in
the
way
they
perform
is
actually
because
that
client
is
having
issues
so
or
does
things
in
some
optimal
way
so
far,
and
what
you'll
see
is
that
they'll
fix
that
right?
So
as
soon
as
you
can
identify?
Oh,
this
client
is
weaker
in
this
area.
It's
going
to
become
a
priority
for
them
and
and
they'll
get
better
very
quickly.
B
The
the
engine
api
that
we
use
to
communicate
with
the
execution
layer
is
a
standard.
It's
a
pretty
simple
standard,
really
there's
like
three
calls
so
yeah,
it
just
works,
and
it's
really
nice
that
they
are
so
well
decoupled.
I
think
it's
it's
a
bit
of
a
misnomer
that
that
you
need
to
have
two
clients
that
are
in
the
same
language
or
things
like
that,
and
you
know
yes,
we're
we're
consensus
that
makes
both
teku
and
baysu,
but
we
are
different
teams.
B
B
We
want
to
look
at
client
diversity.
There's
been
a
lot
of
talk
about
that,
so
you
know
much
as
I
love
the
guest
team.
Maybe
don't
run
geth
right
now
and
let's
bring
its
share
back
down
to
something
a
bit
safer
and
I
you
know
the
same
as
I've
said
about
the
prism
team
in
the
past
and
I'll
say
it
about
the
guest
team.
B
A
Absolutely
yes,
the
client
diversity
is
a
question
that
has
been
there,
especially
for
el
lair,
but
my
understanding
is
it's
because
of
the
it
was
mining
option
that
was
not
provided
by
many
other
clients,
but
hopefully
it
will
be
better
post
march
on
client
diversity.
I
understand
tekko
is
already
at
a
decent
position.
It
has
a
decent
network
share
curious.
If
there
is
any
plan
to
increase
the
current
network
share
or
maybe
to
increase
the
numbers
of
users
joining
the
network.
B
B
You
know
there
is
a
lot
of
support
there
for
teku
and
we'll
keep
keep
working
to
make
protective
as
best
we
can
we'll
optimize
it
we'll
keep
finding
ways
to
to
eat
the
best.
You
know.
Validator
rewards
out
that
we
can
reduce
resource
usage,
implement
features
that
people
want
that
kind
of
thing,
and
you
know
I
think
I
think
that's
all
you
can
do
where
there
are
issues,
that's
something
that
I
think
we've
shown
that
we
can
manage
them
really
well
and
respond.
B
Well,
that's
something
that
I
really
think
is
important.
It's
one
thing
to
see
how
a
client
performs.
I
think
it's
going
well
when
there's
a
problem
is
when
you
actually
want
to
count
on
the
team.
I
think
we
have
a
pretty
good
track
record
there.
Thankfully,
we
haven't
had
to
demonstrate
it
much
but
yeah,
so
I
don't
think,
there's
a
silver
bullet
that
that
will
suddenly
make
everything
work
or
make
it
better,
but
we'll
just
keep
plugging
away
and
keep
contributing
to
the
ecosystem.
B
A
B
Yeah,
I
think,
that's,
I
think
that's
one
of
the
other
interesting
things
is
like
so
we've
talked
about
the
risk
of
slashing,
which
is
all
about
the
share
of
validators,
and
I
think
that's
really
important.
We
want
that
spread
well
across
clients
anyway,
but
there
is
also
the
share
of
non-validating
nodes,
which
is
suddenly
going
to
become
important,
because
that's
where
most
of
the
value
in
ethereum
is
the
validators
don't
control
the
network.
B
The
users
do
so
it's
going
to
be
much
harder
to
find
out
what
that
share
is
and
what
the
value
attached
to
them
are.
But
things
like
you
know,
inferior
runteku
is
actually
a
heck
of
a
lot
of
users
of
tech
and
it's
a
big
responsibility,
so
they
I
expect,
will
diversify,
particularly
for
the
the
cl's
driving
their
execution
layers
for
the
kind
of
execution
electric
layer
apis
that
metamask
used.
I
think
it's
really
important.
B
They
do
diversify,
but
we're
going
to
work
really
hard
to
make
sure
they're
happy
and
and
keep
using
a
lot
of
techie
with
that
mix
as
well.
So
it
will
be
interesting
to
see
what
that
share
of
users
is,
and
then
the
share
of
value
which
is
imaginable,
but
to
get
a
sense
of
that
in
terms
of
where
clients
who
use
post
mode
will
be
quite
interesting
to
see.
B
I'd
probably
say
get
involved
like
there
is.
There
is
a
wonderful
community
out
there
in
so
many
different
places,
so
I
hang
out
in
the
sacred
community
a
lot
and
they're
really
great
at
supporting
validators
getting
up
and
running.
There's
you
know
communities
around
each
client
if
you've
ever
wanted
to
be
part
of
developing
ethereum
get
involved,
say
hi
find
an
issue
that
that
bugs
you
anything
that
bugs
you
about
your
client
is
an
opportunity
to
start
getting
involved
and
there
are
plenty
of
people
around
that
will
help.
B
You
do
that
and
whether
that's
you
know
writing
code,
whether
that's
improving
documentation,
whether
that's
just
providing
support
in
not
just
providing
but
well
that's
absolutely
wonderful
thing
of
providing
support
in
discord
and
helping
other
people.
All
of
that
contributes
to
this
ecosystem.
We
have,
and
it
is
such
a
wonderful
community
that
is
built
in
so
many
places,
there's
clearly
toxic
parts
of
the
crypto
community
as
well.
But
there
are
these
really
gems
of
communities
that
I
think
we
want
to
foster
and
celebrate
and
to
come
and
be
part
of
them.
A
Absolutely
like
what's
bugging,
you
may
also
be
bugging
many
other
people.
You
can
definitely
bring
it
up
and
join
the
community
help
them
resolve
the
issue.
Well,
thank
you.
That's
a
very
sweet
message
and
very
inviting
too
for
community
to
join
in
adrian.
We
appreciate
you
taking
our
time
and
talking
about
teku
sharing
inside
the
preparation
of
merge
and
other
amazing
features
that
we
are
expecting
with
beacon
chain,
node
providers.
Thank
you
for
joining
us
today.
A
With
over
17
network
share,
teku
is
the
third
most
popular,
hidden,
beacon,
chain,
client,
node
provider.
This
clearly
suggests
the
popularity
and
adoption
of
taku
for
beacon
chain
node
drumming
in
the
know,
your
client
series.
So
far
we
have
shared
information
of
four
el
clients,
besu
arigan
get
another
mine
and
including
taku
five
cl
clients,
lighthouse
lodestar,
nimbus,
bresman
chico
check
out
the
playlist.
A
If
you
missed
any
talk
and
join
the
network
soon,
and
on
this
note,
thanks
to
everyone
watching
and
listening
to
this
special
episode
on
the
merge
upgrade,
should
you
have
any
question:
leave
a
comment
or
reach
us
at
eat
cattle.
This
discard
check
out
descriptions
for
link
to
useful
resources
and
guest
twitter
to
follow.
Keep
sharing
your
love
with
ethereum
catalytis
stay
tuned
for
more
ethereum
related
content
coming
up
on,
epenny
cheers
everyone.