►
From YouTube: PEEPanEIP#81: Lighthouse and TheMerge with Mark M.
Description
Topics covered
----------------------------
0:45 - About the client
1:15 - Guest’s introduction
2:40 - About Sigma Prime
3:40 - About Lighthouse
5:36 - Lighthouse Networking
7:20 - Bug - Battle scars: Timing & Timer
09:09 - Fuzzing activities
11:24 - The Merge - Brief overview
11:32 - Consensus Layer & Execution Layer
12:17 - One chain with a sneaky inside chain
12:32 - Execution and consensus client
12:46 - Beacon blocks & Execution Payloads
13:15 - Data Structure - Beacon block
13:33 - Proof of stake: A common misconception
15:37 - Block Processing
21:12 - The road to Merge
21:19 - Optimistic Sync
23:01 - Merge testing
26:35 - Future roadmap - moar testing
28:00 - New features
30:50 - End of presentation - project’s contact
31:19 - Questions
32:24 - MEV boost testing - has it to be done for all Consensus clients?
33:23 - What is a Slashing protection database? How does the Lighthouse client protect a validator?
36:58 - What is Slasher? Does every client run slasher?
38:10 - Significance of a Graffiti? Is it a general CL client spec.
41:22 - Any engineering challenge during testing the Merge?
43:30 - What do you think is the best client combination for Lighthouse?
46:48 - Does Fork choice async feature work with any EL client or specific?
48:21 - Which user base is your primary target? Thoughts on client diversity?
50:14 - EIP-4881 Are you aware of any client implementation?
53:06 - Is there any bounty program?
54:05 - Any advice for Ethereum validators?
Resources:
-----------------
Slides - https://docs.google.com/presentation/d/1a-paVheLtydrfykBzEk0QXdaMKgTzC2OISCcZjrX7H4/edit?usp=sharing
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
-----------------------------------------------
Mark Mackey @EthDreamer | 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
A
Is
an
ethereum
client
developer
mark
also
known
as
dreamer
in
the
web
3
world
is
working
with
the
lighthouse
client
about
the
client
written
in
rust.
Lighthouse
is
focused
on
security
and
performance.
The
project
is
maintained
by
sigma
prime.
We
will
learn
more
about
lighthouse
in
this
episode
with
mark.
Thank
you
for
joining
us.
A
B
Yeah
sure
yeah,
so
I've
I've
been
kind
of
involved
since,
like
2016,
I
really
started
looking
into
ethereum
and
sort
of
slowly
developing
a
a
passion
that
grew
into
an
obsession,
and
then
I
at
some
point
realized
that
I
really
wanted
to
be
a
client
developer
and
finally
made
that
a
reality
in
like
in
2021
april.
So
it's
been
a
little
over
a
year
and
I've
loved
it.
B
So
it's
it's
just
been
working
on
lighthouse,
this
whole
time
and
and
really
getting
completely
absorbed
in
ethereum
before
I
was
working
in
ethereum,
I
had
a
bit
of
a
background
in
high
performance,
computing
and
fintech,
but
yeah
I'm
happy
to
be
here
and
I'm
happy
to
be
in
this
ecosystem.
It's
very
exciting.
A
B
Great
yeah,
so,
like
we
said,
I
I
work
with
sigma
prime.
I
work
in
the
the
lighthouse
client
we've
kind
of
already
done
the
introduction
so
I'll
skip
that
a
little
bit
but
yeah
before
I
talk
a
little
bit
about
lighthouse,
let's
dive
into
a
little
bit
of
who
sigma
prime
is
so
sigma.
Prime,
is
the
company
that
develops
lighthouse
that
I
work
for
and
we
were
established
in
2016
and
we
really
specialize
in
security,
auditing
and
information
security.
B
So
kind
of
our
whole
goal
is
to
improve
the
security
of
all
layers
of
this
of
ethereum,
simultaneously
we're
one
of
the
few
auditing
firms
that
will
actually
is
comfortable
working
on
all
layers
of
the
stack.
So
obviously
we
work
on
the
base
layer
with
lighthouse,
but
we
also
do
things
like
smart
contract,
auditing
and
security
audits
and
we've
even
worked
with
layer,
twos
and
so
there's
a
team
of
about
20
people
and
about
half
of
them
are
that
kind
of
security.
B
Auditing
in
review
and
the
other
half
are
lighthouse
developers
and
we
work
closely
with
the
ethereum
foundation
on
spec
proposals
and
changes
and
and
obviously
working
with
lighthouse
yeah.
So
the
white
house
itself
development
began
in
july
of
2018..
So
that's
significant.
If
you
know
anything
about
the
ethereum
roadmap.
B
They
kind
of
had
these
teams
come
together
and
realize
you
know
we
could
actually
get
a
lot
better,
a
lot
better
result
if
we
unified
this
work
together,
and
so
that's
what
they
did
and
then
in
july
june
they
did
make
that
decision
that
that
that's
officially
what
they
were
going
to
do,
which
was
kind
of
painful.
They
had
to
deprecate
a
lot
of
work
and
then,
in
july
they
sort
of
made
the
public
announcement
that
that's
what
they
were
doing
and
that's
when
lighthouse
development
began.
B
B
B
It's
a
very
dynamic
environment
and
so
you'll
have
to
subscribe
to
different
topics
and
different
sets
of
peers,
and
so
we
try
and
you
you'll
have
to
do
that
quite
quickly,
and
so
we
try
to
maintain
lists
of
peers
that
are
long
lived
at
different
subnets
so
that
we
can
quickly
get
if
we
when
we
need
to
quickly
get
a
set
of
quality
peers
for
a
given
subnet.
When
we
need
to
subscribe
to
that
subnet,
we
try
to
strive
for
like
uniform
uniformity
across
the
list.
B
At
least
we
have
made
a
lot
of
progress
on
that
front.
The
the
networking
layer
has
taken
a
lot
of
pains
to
be
multi-threaded
so
that
we're
really
resource
efficient
and
really
responsive,
it's
modular.
So
there
are
a
couple
of
other
projects
that
do
use
our
networking
layer
and
we
continue
to
develop
more
features
for
it,
there's
episode,
which
is
an
improvement
on
gossip
gossip
stuff.
B
I
might
talk
a
little
bit
more
about
that
at
the
end
and
we
also
have
improvements
to
our
discovery
protocol
as
well
for
topic
discovery
to
kind
of
illustrate
the
point.
We
had
an
interesting
bug
a
little
while
ago,
but
it
did
kind
of
reveal
that
our
peer
scoring
was
working.
So
this
was
like
an
extremely
elusive
bug.
It
took
us
probably
a
month
to
find
where
it
is.
B
B
B
How
long
this
would
have
taken
to
find
if
we
didn't
have
something
that
was
kind
of
raising
that
flag
for
us,
but
it
also
kind
of
speaks
to
the
robustness
of
our
peer
scoring
being
a
security
focused
company.
We
also
do
a
lot
of
fuzzing,
so
if
you're
unfamiliar
fuzzing
is
this
like
automated
testing
technique,
where
you
generate
like
random
or
invalid
or
unexpected
data,
and
try
to
provide
it
as
input
to
functions
in
order
to
try
to
break
them
and
discover
bugs
hopefully
before
those
bugs
reach
production.
B
So
yeah
we've
been
doing
this
since
very
early
on
since
2019
on
just
lighthouse,
but
this
kind
of
expanded
to
where
we're
fuzzing
all
the
clients.
We
especially
heavily
focus
on
fuzzing
the
the
state
transition
functions,
because
this
is
really
core
consensus
code
that
needs
to
be
like
bulletproof,
because
if
there's
a
difference
in
how
different
clients
process
the
state
transition,
you
can
end
up
with
forks
in
the
chain
and
kind
of
like
the
worst
bugs
that
you
can
get.
B
B
So
it's
it's
kind
of
like
using
lighthouses
as
a
way
to
guide
it,
and
this
is
kind
of
all
automated.
But
we
we
do
that
differential
fuzzing
on
all
the
clients,
and
we
found
quite
a
lot
of
bugs.
I
believe
it
suffers
from
40
critical
bugs
that
we've
found
through
this
process
so,
like
I
said
our
mission
is
to
try
to
improve
the
security
of
the
stack
as
best
we
can
yeah.
So
a
little
bit
of
brief
overview
of
the
the
merge
since
we're
talking.
B
That's
what
the
subject
of
this
is
about
it's
right
now
we
kind
of
have
we
have
two
chains.
We
have
the
beacon
chain
or
the
consensus
chain
used
to
be
known
as
the
e2
chain
and
all
that
chain
does
is
really
come
to
consensus
on
what
the
head
of
the
chain
is
and
who's
voting
in
the
chain.
But
there's
really
no
other
information.
It
doesn't
do
anything
else,
so
it's
not
very
useful
right
now,
other
than
in
terms
of
being
a
proof
of
stakeholder
that
comes
to
consensus.
B
The
other
chain
that
we've
known
and
loved
since
2014
is
the
execution
chain
used
to
be
called
the
eve
one
chain,
and
that
includes
all
the
data
that
you
know.
You
expect
from
ethereum
all
the
contracts.
All
the
code
and
all
the
balances
of
all
the
accounts
and
all
of
that,
and
so
the
goal
is
with
the
merge
simple
enough-
is
to
merge
them
into
one
chain.
B
Although
under
the
hood,
it's
not
quite
one
chain,
it's
it's
kind
of
a
chain
with
a
sneaky
chain,
embedded
inside
it
with
the
way
that
this
works
and
because
we
of
this
kind
of
embedding
process.
This
is
why
you're
going
to
need
to
run
after
the
merge
well
and
hopefully
before
the
merge
right,
you're
going
to
need
to
be
running
both
an
execution
and
consensus
client.
At
the
same
time,
in
order
to
be
running
what
is
proof
of
stake?
B
Ethereum
bit
of
note
on
terminology,
we
don't
actually
call
these
things
staking
stuff
and
and
transaction
stuff
at
the
technical
terms,
is
the
beacon
blocks
on
the
proof
of
stake
side
and
inside
burn
bedding
execution
payloads?
So,
basically
like
we're,
embedding
the
execution
block
inside
the
beacon
block
and
then
the
two
clients
kind
of
operate
in
lockstep
and
they
move
forward
together.
Yeah
like
this-
and
you
can
actually
see
this.
B
Payload
is
a
whole
bunch
of
information
about
about
the
execution
block,
and
so,
as
long
as
we're
kind
of
talking
about
the
communication
and
and
how
these,
how
the
merge
happens,
I
want
to
take
the
opportunity
to
clear
up
a
common
misconception
about
proof-of-stake,
because
I
don't
think
anyone's
ever
made
this
point
before,
but
due
to
the
way
that
proof
of
stake
ethereum
is
structured.
You
can.
B
You
can
actually
see
this
in
real
time
and
clear
up
this
misconception.
So
a
lot
of
people
think
that,
because
improved
mistake,
you
you
have
a
vote
and
that's
weighted
by
the
amount
of
stake
that
you
have,
that
the
validators
can
kind
of
do
whatever
they
want
that
they
can.
You
know,
change
the
rules
of
the
consensus
if
they
want
or
they
can
propose
in
valid
state
transitions
or
they
can
like
steal
your
funds.
B
B
That's
that's
easy
to
disprove,
because
ethereum
doesn't
have
any
on-chain
governance,
there's
simply
just
no
way
to
change
the
rules,
the
protocol
on
chain
that
doesn't
exist,
but
the
second
scenario
you
know
what
about
trying
to
steal
your
funds
or
what
about
in
proposing
a
valid
state
transition?
That's
a
little
more
subtle
or
nuanced,
and
it's
not
just
like
bitcoin
maxies
that
get
this
wrong.
B
It's
people
that
are
well-intentioned
and
generally
know
a
lot,
so
the
person
on
the
right
is
actually
one
of
the
the
co-founders
of
polygon
who
had
gotten
this
wrong
and,
in
my
personal
conversations
with
people,
I've
talked
to
people
that
are
generally
knowledgeable
that
I've
also
gotten
this
wrong.
And
so
I
want
to
clear
this
up
because,
due
to
the
structure
of
the
merge,
you
can
actually
look
under
the
hood
and
see
that
this
is
not
the
case
and
see
why.
B
In
order
to
see
why
we're
going
to
talk
a
little
bit
about
block
processing
and
how
block
processing
happens
after
the
merge
so
basically
you'll
have,
what
will
happen?
Is
a
beacon
block
will
come
in
from
the
network
on
the
beacon
chain
or
on
the
on
the
consensus
side,
and
just
as
normal
and
the
consensus
site
will
do
a
little
bit
of
validation
on
it
and
embedded
in
that
beacon
block
is
going
to
be
the
execution
payload.
Now,
that's
your!
B
That's
all
the
information
about
how
the
state
changes
under
the
application
of
this
block,
the
execution
side
or
the
the
consensus
side
doesn't
know
whether
or
not
that
state
change
is
valid
and
consequently,
whether
or
not
the
entire
block
is
valid.
So
it
has
to
ask
the
execution.
Client
is
this:
is
this
execution
payload
valid?
Does
it
follow
the
rules
of
the
protocol,
and
I
wrote
this
thing
called
json
rpc
snoop
that
lets
you?
B
You
can
stick
between
the
execution,
client
and
the
consensus
client,
and
you
can
actually
view
the
communication
between
the
two
and
so,
if
you
do
that,
you
will
actually
see
this
happen
in
real
time.
So
on
the
screen,
right
now,
if
you're
listening,
you
can
see
the
requests
going
out
from
the
consensus
client
to
the
the
execution
engine
of
saying:
hey,
I've
got
a
new
execution
payload
here.
Can
you
tell
me
if
this
is
valid
and
the
execution
client
will
take
a
look
at
it?
B
The
execution
client
will
send
back
to
the
consensus
client
that
that's
valid
and
again,
if
you're
running
the
snooper
between
and
you're
looking
at
the
communication,
you'll
actually
see
this
and
so
like
on
screen.
You
can
see
the
message
and
you'll
see
that
it
has
a
big
valid
in
it
to
say
this
block
is
valid
and
at
that
point
the
consensus
client
will
persist.
B
This
block,
you
know,
it'll,
ensure
that
this
block
is
valid
or
it'll
say
that
this
block
is
invalid
and
it
will
make
it
the
head
of
the
shame
and
it
will
let
the
execution
client
know
with
a
message
that
says
this
is
now
the
head
of
the
chain
again,
if
you're
running
the
snooper,
you
can
see
this
happen
real
time.
You
hear
here
there's
a
message
saying
this
is
the
new
head
of
the
chain
and
there's
a
response,
an
acknowledgement
from
the
execution
engine
and
sure
enough.
B
If
you're
watching
the
logs,
what
you'll
see
is
new
blocks
will
come
in
and
each
time
because
blocks
are
being
added
onto
the
chain.
The
hash
at
the
head
of
the
chain
is
going
to
change
because
new
blocks
are
coming
in
with
a
new
block
hash,
and
so
you
can
see
that
in
the
logs
now
what
happens
in
case
two
where
the
block
is
invalid.
B
Well,
in
that
case,
the
execution
client
is
going
to
notice
and
it's
going
to
send
back
a
message
saying
it's
invalid
and
in
our
merge
testing.
We've
actually
seen
this
happen
because
there's
been
bugs
in
the
block
production
code
before
some
of
the
minority
clients
that
that
haven't
been
as
well
tested,
because
almost
all
the
miners
were
wrong
to
get
so.
B
The
earlier
statement
from
from
this
czech
matey
person,
they
were
saying
you
know
that
validators
are
the
ones
that
are
doing
the
validation,
but
that's
not
actually
true
all
the
nodes
in
order
to
be
participating
in
ethereum
every
every
node
that
runs
for
support
for
adapt
or
for
infera
or
for
exchanges.
All
nodes
are
going
to
do
all
validation
of
all
blocks.
It's
the
same
thing
as
bitcoin.
B
One
of
the
things
that
came
up
that's
kind
of
interesting
to
talk
about
is
optimistic
sync,
so
this
kind
of
came
up
semi
by
surprise
in
amphora,
so
it
has
to
do
with
like
a
nuance
of
of
syncing
and
how
singing
happens.
So
you
know
if
you're,
already
all
synced
to
the
head
of
the
chain
and
you're
just
proceeding
in
lockstep
all
is
well
and
good.
But
what
happens
when
you
know
the
execution
engine
isn't
synced
or
both
both
clients
are
thinking
but
they're
behind
the
head.
B
They'll
have
something
that
goes
ahead
and
just
verifies
the
the
proof
of
work
of
each
block,
and
then
they
can
kind
of
backsync
in
batches.
So
it
sort
of
leverages
the
existing
code
and
existing
syncing
algorithms.
By
doing
this
optimistic
thing,
but
it
was
something
that
required
a
lot
of
thought
and
eventually
we
had
to
come
up
with
a
spec
for
optimistic
sync
and
that
all
was
work.
That
happened.
B
You
know
after
amphora,
but
before
now,
and
I
believe
most
of
the
clients-
and
I
think
all
clients
have
implemented
it,
and
so
that
enables
the
execution
ends
to
sync
quite
quickly.
We've
obviously
been
doing
a
lot
of
merge
testing
we've
like
like
said
in
the
beginning.
We
have
had
nine
shadow
forks,
including
one
that
was
yesterday
and
we've
we've
merged
robson
and
we've
merged
the
polia
and
those
have
pretty
much
gone
well.
B
There
was
like
a
minor
issue
on
sepolia,
where
it
wasn't
any
issue
with
lighthouse
at
all.
It
was
literally
just
a
configuration
issue.
If
you
remember
what
happened
on
robston.
Was
the
the
miners
jumped
a
bunch
of
hash
rate
on
robson
and
then
kind
of
fast
forwarded
the
chain,
and
then
we
had
to
like
override
the
ttd
via
the
command
line.
The
the
terminal
difficulty
is
the
the
difficulty
at
which
the
merge
is
triggered,
so
they
fast
forwarded
the
chain
so
that
we
would
hit
that
sooner
than
we
wanted
to.
B
So
we
had
to
push
it
back
by
manually
overriding
it
and
unfortunately,
in
our
scripts.
We
simply
left
that
manual
override
in
the
scripts
when
we
did
the
subholy
emerge
and
we
that
was
unintentional.
So
we
all
we
had
to
do
is
move
that
remove
that
command
line
lighthouse
merged
just
fine,
but
it
did
cause
a
little
bit
of
a
stir,
and
then
we
had
like.
I
said
we
yesterday
or
I
would
say
wednesday
night,
we
had
a
merge
of
main
net
shadow
fort
nine.
This
one
was
a
little
weird.
B
I
think
the
hash
rate
on
mainnet
got
a
little
irregular
or
there
was
something
wrong
with
the
the
ttd
prediction
code
that
we
use
to
kind
of
guess,
a
terminal
total
difficulty,
because
usually
with
these
shadow
forks,
we
guess
a
far
future
difficulty.
That's
not
going
to
be
hit
and
then,
as
we
get
closer
to
where
our
predictions
get
more
accurate.
Like
two
days
before
we'll
release
a
new
difficulty
and
everybody
has
to
like
reboot
their
nodes
with
the
new
difficulty.
B
But
this
difficulty
actually
triggered
much
sooner
than
we
were
expecting
so
like
we
all
like.
We
had
some
nodes
that
merged
too
quickly,
and
then
they
had
to
be
re-synced
and
then
so
we
pushed
the
difficulty
back
and
that
still
actually
merged
eight
hours
sooner
than
we
were
expected.
So
there's
a
little
bit
of
chaos
there
that
all
had
to
do
with
around
predicting
the
terminal
difficulty.
B
But
this
isn't
something
that
is
is
an
issue
with
the
main
net,
because
we're
not
going
to
be
trying
to
get
the
exact
timing
right
to
within
you
know
a
couple
hours
and
we're
not
going
to
be
giving
users
just
under
a
week
to
sync
everything
and
get
all
up
to
date.
You'll
have
a
lot
more
time,
but
and
then
we
did
sort
of
discover
a
small
sinking
issue
in
in
lighthouse
as
well.
B
During
that
shadow
fork,
nine,
there
was
an
issue
where
we
were
being
overly
strict
with
our
detection
of
bad
change
in
ways
that,
like
we
basically
had
counted,
we
had
counted
networking
errors
as
as,
if
we
had
been
seeking
an
improper
chain
and
we
fixed
that
bug
and
we've
deployed
that
pull
request
to
to
the
shadow
forks
and
things
are
running
fine
now,
but
yeah,
just
minor
things
and
it
looks
like
the
guerrilla
merge
will
be
mid-august.
That's
the
word
on
the
street
anyway.
B
So
we're
looking
forward
to
that
that'll
be
our
kind
of
first
merge
of
a
long-running
beacon
chain,
because
prater
has
been
running
for
a
long
time.
So
we're
very
excited
for
that.
But
in
the
meantime,
we're
gonna
be
keep
we're
gonna,
keep
running
these
shadow,
forks
yeah,
so
future
directions
we're
going
to
shadowfork
every
week
until
the
merge,
unless
there's
a
unless
it's
probably
not
the
week
that
that
guerrelli
merges
but
every
other
week.
B
Just
because
this
this
keeps
giving
us
more
confidence
in
our
in
our
code,
and
you
know
we
continue
to
improve
our
clients.
So
there's
new
changes
every
week
that
we
still
want
to
test
the
merge
underneath
so
there's,
there's
med
boost
testing
so
after
the
merge
stakers
will
be
able
to
extract
minor
minor
extracted
value
from
from
the
blocks,
so
there's
an
entirely
new
protocol.
For
that
that's
different
than
the
way
this
has
happened
on
the
proof
of
work.
B
That's
been
built
from
the
ground
up,
so
that
needs
a
lot
of
testing.
It's
not
like.
That's
delaying
the
merge
or
anything,
but
that
is
happening
in
parallel.
We
are
improving
our
logs
to
try
to
alert
users
of
potentially
bad
configurations
so
that
we
log
wildly
so
that
they
would
notice
any
issues
before
the
merged
would
ever
happen
and
we're
improving
our
docs
for
users
to
have
merge.
B
Readiness,
I
believe
it
should
be
really
soon
here,
because
we're
getting
down
we're
getting
in
the
final
stretch
to
where
users
can
start
to
upgrade
their
nodes
to
be
merged
ready.
Even
if
we
haven't
announced
the
ttd
yet
there's
a
lot
of
new
features
in
the
pipeline.
One
that's
coming
very
soon
is
we've
just
made
our
fork
choice
asynchronous.
This
has
helped
improve.
B
Basically,
this
gives
us
this
lets
us
give
the
execution
engine
much
more
time
to
propose
a
block.
It
kind
of
helps
us
overlap,
communication
with
the
execution
engine
and
block
processing.
So
it's
a
little
more
efficient
and
that's
already
been
merged
in
time.
Stable,
so
that'll
make
its
way
to
the
next
release.
I
would
imagine
tree
states
is
something
that
michael
sprawl
has
been
working
on
for
a
long
time.
B
It's
this
interesting
way
of
storm
of
mercalizing,
beacon
states,
and
this
allows
you
to
store
a
lot
more
beacon
states
and
memories.
So
this
improves
our
efficiency
under
reorgs
and
things
like
that
and
improves
our
hashing,
and
it's
also
just
good
for
like
when
you
need
to
look
back
at
an
earlier
version
of
the
beacon
state.
There's
certain
situations
where
you
do
that,
so
we
can
maybe
eliminate
some
caches
that
we
have
in
the
code
eip
4881
deposit
snapshots.
B
So
that's
an
eip
written
it's
nice,
because
when
you
sync
a
beacon
node,
you
have
to
download
all
the
deposit
logs
since
they
launched
the
deposit
contract
and
that
generally
takes
upwards
of
like
an
hour
to
two
hours.
So
the
the
deposit
snapshots
are
ways
where
you
can
utilize
the
properties
of
merkle
tree
and
make
this
sync
in
seconds.
B
So
that's
really
nice,
because
once
those
are
out,
basically,
you
can
go
from
nothing
to
having
a
beacon
client,
that's
fully
ready
to
participate
and
validate
and
propose
blocks
in
a
matter
of
a
minute
and
most
of
that
time,
it's
just
downloading
blocks
from
the
execution
engine,
so
that'd
be
really
cool
to
be
out.
Episode
is
an
improvement
on
gossip
sub.
B
That
will,
let
us
reduce
our
bandwidth
dramatically
so
that
that
we've
been
working
on
there's
also
improvements
to
our
discovery
that
will
enable
us
to
do
topic
discovery,
that's
kind
of
been
in
the
in
the
works.
For
a
long
time,
michael
strahl
has
been
working
on
improving
our
block.
Packing
algorithm
he's
going
to
write
a
blog
post
about
that
and
the
efficiencies
that
we
get
so
stay
tuned.
For
that
we
may
at
some
point
build
a
like
client
we're
not
it's
not
like.
B
We've
definitely
committed
to
that,
but
that's
that's
a
possibility
and
then
we're
just
kind
of
keeping
up
with
all
the
changes
that
all
the
clients
are
requiring,
I'm
sure
the
day
after
the
merge.
The
next
topic
will
be.
When
is
shanghai,
and
so
there's
a
lot
of
there's
just
a
lot
of
things
happening
all
the
time
so
yeah,
that's
that's
the
talk,
and
thanks
for
listening.
If
you're
running
lighthouse,
please
follow,
follow.
Stick
pio
on
on
twitter
that
way,
you'll
know
you're
getting
the
latest
updates.
B
A
A
B
A
All
right,
I
have
got
a
few
more
questions
that
we
have
collected
from
the
community
already.
I
will
try
to
quickly
take
some
of
them,
but
before
that,
I'm
picking
something
that
you
have
mentioned
in
your
slides
about
mav
boost
testing.
Is
it
something
that
is
a
that
is
to
be
done
on
all
client
level
or
is
it
something
that
has
to
be
done
on
lighthouse
level.
B
A
B
But
it
will
need
to
be
done
in
the
consensus.
All
the
consensus.
Clients
will
need
to
be
changed.
We'll
need
to
have
changes
to
do
that
now.
I
believe
teku
and
prism
both
already
have
their
mev
boost,
implementations
out
that's
under
development,
in
lodestar
and
nimbus
and
under
development.
At
lighthouse.
We
we
have
a
pull
request
that
you
can
test,
but
it
hasn't
been
merged,
yet
so
we're
at
different
stages,
but
we're
all
pretty
close.
A
All
right,
so
my
next
question
is
related
to
the
slashing
protection
database,
like
among
other
things.
Validators
are
usually
concerned
about
the
penalties
and
we
know
that
penalty
is
going
to
be
much
higher
than
what
it
was
in.
The
altair
upgrade
right,
so
maybe
talk
more
about
slashing
protection,
database
and
lighthouse,
and
if
this
hasn't
happened
already,
maybe
an
imaginary
situation
where
you
think
running
lighthouse
node
will
help
protect
a
validator
from
functioning.
B
B
He
had
spearheaded
an
eip
that
standardizes
the
format
so
that
you
can
actually
hopefully
transfer
the
slashing
database
from
one
client
to
another.
If
you
do
want
to
switch
clients,
I
don't
know
how
many
clients
have
implemented
it
yet,
but
we
certainly
have
but
yeah.
So
we
have
this
database
and
it
ensures
that
your
validator
client
will
never
sign
a
message
that
could
potentially
get
you
slashed
now.
B
How
does
it
do
that?
Well,
the
only
way
to
sign
a
message
that
would
get
you
slashed
is
to
to
conflict
with
another
message
that
you've
previously
proposed.
So
the
point
of
the
database
is
to
look.
You
know,
keep
everything
you've
already
you've
already
signed
and
ensure
that
whatever
new
message
is
about
to
go
out,
it
doesn't
conflict
with
any
of
those.
B
So
not
only
do
we
have
that,
but
we've
made
it
as
easy
as
possible
to
migrate
that
so,
if
you're
in
a
situation
a
lot
of
validate,
you
know,
a
lot
of
people
become
understandably
nervous
when
they
need
to
move
their
validators
and
they're
gonna
need
to
move
to
another
client.
I
mean
I've
done
this
on
mainnet.
You
can
actually
export
your
slashing
database
and
re-import
it
later
or
into
your
new
validator
set.
So
you
can
ensure
that
you
know
your
slashing
database
goes
with
you
and
you.
B
You
still
have
that
protection.
That's
one
of
the
forms
of
protection.
Another
form
we
have
is
doppelganger
protection,
where
lighthouse
will
basically
listen
on
the
network
and
look
for
anyone.
That's
signing
messages
for
your
validator,
like
if
you're
just
about
to
spin
up
a
new
validator,
and
you
enabled
operator
protection
before
it
starts
signing
anything.
It's
just
going
to
watch
the
network
and
make
sure
that
nothing
else
is
signing
with
your
keys.
That
doesn't
want
you
to
get
slashed.
B
At
the
same
time,
that's
kind
of
the
that's
that's
the
dog
in
your
protection,
but
slashing
database
is
also
there
in
case,
and
so
you
kind
of
have
two
layers
there
like
in
case
there
was
some
issue
where
you
didn't
import
your
slash
database
or
something
like
that.
You
can
have
this
kind
of
dual
protection,
so
we
feel
pretty
confident
that
you,
if
you're,
if
you're
sim,
if
you're
migrating
your
client,
you
shouldn't
get
you
shouldn't,
get
so
much.
A
A
B
You
will
cause
that
validator
to
be
slashed
and
removed
from
the
validator
set,
and
you
will
also
be
incentive.
You
will
get
a
reward
for
doing
that
now.
You
can
actually
run
this
slasher
in
two
modes.
There's
like
an
individual
mode,
where
only
you
will
keep
any
data
that
you
find,
but
there's
also
an
altruistic
mode
where,
if
you're
just
trying
to
provide
security
to
the
network,
you
can
run
your
slasher
yourself.
B
But
if
you
find
anything,
it
will
actually
gossip
that
over
the
network
and
so
any
validator
that
sees
that
gossip,
probably
the
next
block
proposer,
will
include
that
slashing
and
I
do
think
the
ethereum
foundation
runs
some
of
those.
So
it's
kind
of
a
security
model
where
you
just
need
it's
one
event,
but
obviously
best.
If
multiple
people
run
slashers
but
yeah
you'll,
you
stand
to
gain,
you
stand
to
gain
from
doing
it
and
also
you're
providing
security
to
the
network.
A
All
right
I
mean
definitely,
this
is
not
a
good
thing
to
have
money
from
getting
it
from
someone
else,
but
it
is
required
for
the
security
of
netflix,
so
yeah,
why
not
right
all
right?
My
next
question
is
related
to
graffiti.
Like
I
know
like
it's
an
interesting
feature,
I
don't
know
it
is
an
option
and
that
I
consider
it
as
a
meme
for
the
u.s
world.
So
could
you
talk
about
graffiti
like?
B
Yeah
it's.
The
graffiti
is
like
a
32
byte
field
that
is
included
in
any
beacon
block
as
part
of
the
spec,
so
you
can
put
whatever
you
want
in
in
that
in
those
32
bytes
and
the
next,
like
most
client
implementations,
have
it
where
you
can
set
your
graffiti
and
then
the
next
time
you
post
a
block
like
whatever
you
set
in
there
will
be
embedded
in
your
block.
This
is
yeah
a
lot
of
times
it's
just
kind
of
for
me
around.
B
B
B
A
A
That
is
nice
talking
about
test
nets
and
knowing
the
history
of
lighthouse,
it
is
a
client
which
was
there
since
the
beginning.
So
obviously
you
have
participated
in
all
the
testnet
that
happened.
Would
you
like
to
talk
about
any
engineering
challenge
during
this
preparation
for
march
or
testing
the
merge.
B
For
sure
yeah
I
mean
at
first
before
we
kind
of
had
perry.
We
were
just
like
I
mean
he
was
around,
but
we
were
in
the
very
early
stages
like
at
m4
up.
We
were
just
literally
like
setting
up
our
laptops
next
to
each
other
and
trying
to
run
yeah
just
one
node
next
to
another,
I'm
just
trying
to
try
out
these
pairs
with
a
one
node
test
net
for
a
while.
B
I
had
even
tried
to
develop
something
where
you
could
spin
up
a
multi-client
test
net
on
your
your
local
machine
to
try
to
test
the
interop
between
all
the
clients
yeah.
Most
of
the
challenges
around
that
just
have
to
do
with,
like
all
the
clients
are
subtly
different
in
the
ways
that
you
pass
command
line,
flags
and
spin
up
the
node,
and
so-
and
you
know
no
one
developer
works
on
all
the
clients,
so
you
kind
of
have
to
get
used
to
each
client.
B
If
you're
trying
to
do
that
and
build
that
so
yeah.
I
I
I
mean
big,
shout
out
to
perry
because
he's
done
such
a
fantastic
job
and
can
can
spin
up
these
test
nets
all
day,
and
now
we
have
these
awesome
tools
like
kurtosis
and
stuff
that
where
it's
like,
you
can
figure
one
yaml
file
and
then
you
can
spin
up.
You
know,
however,
whatever
kind
of
network
you
want
with
whatever
kind
of
clients
you
want.
B
A
That's
right,
yeah,
I
remember
like
kudos.
This
is
helping
a
lot
and
working
on
different
line.
Combination
definitely
help
with
the
increased
interoperability
right.
We
have
able
to
just
test
a
different
variation
of
client
combination.
Talking
about
client
combination.
Do
you
think
there
is
any
best
client
combination
for
lighthouse.
B
I
would
recommend
that
people
give
nether
mind
and
basically
try
perhaps
another
mind
if
you
want
to
narrow
it
down
to
one
because
they've
been
because
they're
not
yet
like
you
know,
I
love
yes,
nothing
against
geth
and
they're,
not
a
fork
of
death,
either.
Not
that
not
that
I
have
anything
against
aragon.
I
think
they're
fantastic
too.
B
It's
just
that
we,
you
know,
as
we
know,
geth
is
currently
80
of
the
network
and
we've
done
a
lot
of
work
on
client
diversity
on
the
consensus
side,
but
the
execution
side
absolutely
needs
it.
This.
This
kind
of
keeps
me
up
at
night.
Like
you
know,
in
software
a
lot
of
times,
people
think
like
do
what
everybody
else
is
doing
and
you're
kind
of
safe.
B
It's
the
opposite
with
ethereum
it's!
It
is
actually
the
opposite.
It's
not
just
for
the
good
of
the
network,
but
it's
for
the
good
of
your
own
profits
that
you
run
a
minority
client,
because
if
you're
on
a
majority
client
that
has
like
a
bug
in
the
evm
and
we
end
up
finalizing
an
invalid
state
transition,
you
can
lose
up
to
70
of
your
stake,
like
roughly
just
calculating
it
out
before
you'll
finally
start
to
get
validating
again.
So
you
definitely
want
to
be
running.
B
Like
I
mean
obviously
running
aragon
is
better
than
running
guesth,
but
aragon
is
ultimately
a
fork
of
gas,
and
so,
if
there's
a
bug
in
gas,
evm
implementation,
it's
very
likely
that
there's
also
the
same
bug
in
the
aragon,
and
you
could
end
up
also
losing
money
so
and
and
and
it's
kind
of
like
nethermind
and
and
base
who
are
criminally
underrepresented
on
the
network.
So
I
really
encourage
people
to
give
that
a
shot.
A
Right
yeah,
I
know
the
client
diversity
on
el
client
side
is
a
little
weird,
but
my
understanding
is
one
of
the
basic
reason
may
have
been
the
the
proof
of
work
mining
option,
provided
it
wasn't
provided
by
most
of
the
client
like
arygon
does
not
do
that.
Netherman
does
not
do
that
and
that's
why
get
has
been
like
always
the
leader,
but
I'm
hoping
with
this
merge
the
numbers.
The
stats
will
change
and
it
will
be
like
more
decentralized.
B
A
Right,
I
will
add
that
link
here.
That
is
really
a
good
post.
I
will
add
the
link
to
the
description
of
this
video
so
yeah.
I
have
one
more
question
on
the
feature
that
you
mentioned
for
choice,
async
right
and
I
mentioned
that
it
would
probably
provide
more
time
to
eel
blocks
to
propose
their
blocks.
B
Yeah,
it's
for
any
client
combination,
so
basically,
like
the
execution
engines,
aren't
always
working
away
to
ensure
that
they
have
a
block
ready
to
go.
They
have
to
be
told
ahead
of
time.
Hey
I'm
about
to
need
to
propose
a
block
so
get
one
ready
for
me,
and
that
just
saves
on
cpu
resources
and
stuff
like
that.
But
I
do
need
to
be
told
ahead
of
time
that
they're
about
to
be
asked
for
a
block,
so
that
gives
them
ample
time
to
like
start
putting
one
together.
B
The
asynchrony
of
fork
choice
allows
us
to
like
basically
be
like
as
soon
as
we
know,
we're
gonna
need
that
we
can
send
a
message
to
them
being
like
we're.
You
know
start
start
working
on
this,
then
we'll
continue,
processing
block
crossing
and
then
it's
on
the
order
of
like
several
seconds
later,
which
should
be
plenty
of
time
from
before
we're
like
all
right.
Where's.
That
block
that
we
asked
about-
and
you
know
just
giving
the
client
more
time
is
generally
better.
A
A
B
Well,
we
we
target
everyone,
but
there
are
some
people
that
maybe,
like
us
a
little
more
like.
Definitely
your
your
security
focused
person
or
your.
What
would
you
say?
Linux
users
tend
to
tend
to
gravitate
towards
us
and
a
lot
of
staking
pools
do
use
us
as
well,
but
we're
you
know
doing
everything
we
can
to
try
to
provide
the
best
experience
we're
coming
out
with
the
ui
soon
giving
people
a
nice
graphical
interface.
B
A
B
A
B
Right
yeah,
actually
nimbus
has
already
implemented
it,
the
the
merge
or
the
pull
request
for
lighthouse.
It's
been
in
the
queue
for
a
long
time.
The
problem
is,
it's
quite
a
there's
like
a
lot
of
changes,
and
since
we
have
the
merge
coming
up
we've
like
kind
of
delayed
big
changes,
because
we
don't
want
to
try
to
you
know
we
don't
introduce
any
potential
bugs
right
before
the
merge
and
so
like
kind
of
the
big
pull.
B
Requests
have
a
little
bit
of
been
a
little
bit
on
the
back
burner,
but
it's
been
sitting
there
for
a
long
time,
and
so
soon
it
will
be
in
lighthouse.
But
it's
already
in
nimbus,
which
is
really
cool.
Lodestar,
has
has
kind
of
like
expressed
interest
in
implementing
it.
I
I
did
a
lot
of
work
on
the
eip
to
try
to
make
it
like
really
easy
for
client
implementers.
B
B
I
don't
know
this
is
kind
of
my
first
foray
into
like
the
ethereum
governance
process,
so
I'm
new
to
it
I'll
keep
proposing
but
I'll
keep
working
towards
it,
but
I
have
suspect
that
it
might
just
kind
of
like
fly
a
little
under
the
radar
and
we'll
just
kind
of
implement
it
and
kind
of
get
more
clients
on
board
and
just
kind
of
peer
pressure
people
into
doing
it,
because
it's
not
like
this
big
contentious
change.
It's
a
nice
feature,
you
know
and
it's
a
good
standard,
so.
A
I
hope
it
will
be.
I
haven't,
got
a
chance
to
look
into
it,
but
definitely
I
have
seen
very
less
proposal
on
interface
side
and
that
too
coming
up
from
for
consensus,
layer,
clients.
So
I'm
hoping
that
this
is
going
to
be
a
good
feature,
change
request
and
definitely
it
will
not
go
unnoticed
and
that's
why
we
have
this
penny
series.
So
in
the
series
we
talk
about
proposals,
so
maybe
we
will
have
you
in
future.
B
A
Of
course,
of
course,
we'll
try
to
have
you
scheduled
for
that.
Well,
thank
you
so
much
once
again
and
okay,
my
last
set
of
questions
are
from
the
community
side.
The
official
webpage
suggests
that
project
team
welcomes
community
participation,
which
is
obvious,
because
this
is
an
open
source
project.
B
Well,
there's
the
general
ethereum
bug
bounty,
but
we
don't
have
one
specific
for
sigma,
prime,
but
but
the
ethereum
foundation
does
provide
a
bug
value
for
you
to.
You
can
get
up
to
250
000
for
finding
a
critical
bug
and
either
like
the
evm
code
or
a
client
code,
and
things
like
that
and
they
have
been
paid
out
before
so
yeah,
especially
if
you're
considered
security-minded,
and
you
want
to
take
a
crack
at
that.
We
would
absolutely
welcome
it
and
you
can
make
some
serious
serious
cash.
A
B
A
A
A
We
hope
today's
talk
will
help
users
learn
about
another
consensus
layer,
client
provided
to
join
the
network
if
you
don't
want
to
miss
being
a
part
of
this
emerging
technology,
consider
running
an
ethereum
validator
node
today,
and
on
this
note,
thank
you
to
everyone
watching
or
listening
to
the
special
episode
on
the
merge.
Should
you
have
any
question:
leave
a
comment
or
reach
us
at
eath
cat
herders.com
check
out
description
for
links
to
useful
resources
and
guests
twitter
to
follow
we'll
be
back
soon
with
another
episode
on
know.