►
Description
Topics covered
-----------------------------
1:12 - Guests introduction
3:22 - Presentation outline
4:56 - What’s coming with Prysm Altair support
5:00 - Major Revamp: Prysm V2
9:20 - Unique challenges of Hardforks in Go
9:52 - How Prysm is handling fork - Potential Solutions
13:47 - Improving our code is key
14:22 - SOLID Software Principles
15:45 - Clean validation pipeline
16:46 - Where does the new code live?
16:55 - Core transition
18:04 - Network
18:25 - Validator
18:50 - Optimization behind peer implementation
19:20 - Beacon state structure
19:50 - New spec test
20:08 - Testing the fork transition
21:33 - End to end testing
22:47 - What does an evaluator look like (sample codes)
23:40 - How to contribute
24:24 - We are hiring!
24:54 - Q&A
25:36 - Where to run the new slasher - same or different machine?
26:50 - Client diversity - Will the interface tool that is created make it easier for people to switch to a different client or do you think the community should develop?
29:49 - For the validator, will anything change with Altair?
31:09 - Are the Altair clients already in releases?
31:35 - Is Prysm ready for Artair?
32:22 - Testing side - how much testing standards can be shared & tested with the other team?
35:02 - How does developing this software project differ from previous software projects?
37:33 - How do you decide what’s going to go into a release?
39:49 - How do you decide when it is ready?
43:10 - What can the community do to support this effort?
45:53 - Is the availability of documentation makes Prysm the first choice for setting up a beacon chain node?
48:10 - Which is good to follow for information on Prysmatic Labs Medium or hackmd?
49:00 - What as a community can we do to support Client Diversity?
50:32 - What is the reason for a decrease in Eth1 nodes?
52:30 - Thoughts on using the staking pools?
54:15 - Impact of Altair on validator - What are the chances of a decrease in rewards for solo stakers considering sync committee?
55:48 - Shout out to the Prysm team members
Resources
-------------------
Slides: https://docs.google.com/presentation/d/1pK4YsRTvYmffsfSGD5eAoYvzdFDVsbwooZON3wtGpd8/edit#slide=id.p
Beacon chain proposal - https://www.youtube.com/playlist?list=PL4cwHXAawZxoEw29YmqJtNoFaENUUAREn
PEEPanEIP playlist - https://www.youtube.com/playlist?list=PL4cwHXAawZxqu0PKKyMzG_3BJV_xZTi1F
Follow at Twitter
-----------------------------------------------
Terence Tso @terencechain | Raul Jordan @rauljordaneth | Superphiz @superphiz | Colfax Selby @colfaxselby | Pooja Ranjan @poojaranjan19
Check out upcoming EIPs in Peep an EIP series at https://github.com/ethereum-cat-herders/PM/projects/2
Contact Ethereum Cat Herders
---------------------------------------------------
Discord: https://discord.io/ethereumcatherders
Twitter: https://twitter.com/EthCatHerders
Medium: https://medium.com/ethereum-cat-herders
GitHub: https://github.com/ethereum-cat-herde...
Email: support@ethereumcatherders.com
Website: https://www.ethereumcatherders.com/
A
Welcome
to
another
episode
of
penny,
an
educational
series
where
we
learn
about
improvement,
proposals,
upcoming
features
and
updates
on
ethereum
blockchain,
I'm
your
host,
pooja
ranjan
and
I'm
joined
by
superfiz
and
cold
facts
from
each
stakers
community.
Today,
in
this
episode,
we'll
be
talking
about
the
preparation
of
altair
from
a
client's
perspective,
their
experience
of
implementing
features
and
running
the
devnet
and,
of
course,
the
roadmap
of
the
client
prism.
A
A
C
C
You
should
check
out
this
ethereum
thing,
so
I
so
I
started
reading
more
about
it
and
then
I
couldn't
figure
out
where
to
contribute
for
the
longest
part,
because
there's
just
so
much
going
on
and
then
luckily
I
think
it
was
the
early
2018.
I
joined
this
ready
thread
and
then
they
were
asking
for
people
looking
for
people
there
working
on
ethereum
scalability
and
then
I
look
at
the
reddit
thread.
C
B
B
One
can
possibly
do
and
really
that
was
implementing
proof
of
stake,
and
you
know
over
the
coming
months
and
maybe
years
that
rapidly
became
the
effort
known
as
e2,
and
now
here
we
are,
you
know,
on
main
net
with
you
know,
with
all
these
things
launched,
I
remember
terence
in
the
beginning
was
like.
I
really
want
to
improve
at
doing
research
work
and
now
he's
a
number
one
contributor
to
the
e2
specification
outside
of
the
ethereum
foundation.
B
A
Interesting,
thank
you
so
much
for
introduction.
I
really
love
this
section
of
the
show
like
it
brings
us
so
much
closer
to
know
more
about
the
contributors
of
ethereum
ecosystem
and
I
really
hope
that
these
stories
will
inspire
the
young
generation
exploring
technologies.
So
without
further
ado,
let's
peep
in.
B
Okay,
excellent
yeah,
so
today
we're
going
to
be
giving
a
high-level
overview
of
prism,
our
e2
client
and
how
we're
dealing
with
the
altair
hard
fork,
which
is
coming
up.
You
know
in
probably
within
a
month
to
mainnet
the
alter
hard
fork
is
the
first
major
upgrade
to
the
ethereum
beacon
chain.
It's
a
planned
network
upgrade
some
of
the
things
that
you
know
are
included.
B
The
specific
details
are
out
of
scope
for
this
presentation,
but
at
a
high
level,
really
a
lot
of
optimizations
that
will
just
improve
the
ethereum
2.0
network
itself
and
also
a
lot
of
cool
features
that
are
coming,
such
as
support
for
light
clients.
So
you
know
like
client.
Support
has
been
always
something
that
is,
is
really
critical
for
blockchain
being
able
to
have
a
very
a
minimally
validating
piece
of
software.
That
can
you
know
that
can
basically
track.
B
The
chain
is
a
very
powerful
construct
that
allows
us
to
do
a
lot
of
really
cool
things
and
preserve
decentralization,
so
altair
is
kind
of
bringing
all
that
to
life,
and
we
encountered
a
lot
of
very
specific
challenges
when
supporting
altair.
You
know
thinking
ahead
about
how
to
structure
our
project,
how
to
make
it
maintainable
and
how
to
test
things
for
safety.
B
So
without
further
ado,
let
me
get
started
on
the
next
slide
cool,
so
yeah,
so
we'll
be
covering
kind
of
what's
coming
up
next
in
our
outdoor
support.
Some
of
the
challenges
itself
that
we
had
when
trying
to
implement
a
hard
fork
in
in
our
in
our
programming
language
of
choice,
how
we're
actually
testing
kind
of
like
the
the
fork,
transition
and
and
kind
of
how
that
looks
like
in
our
day-to-day
and
yeah,
just
some
more
information
about
how
to
contribute
for
those
of
you
that
are
interested
so
yeah.
B
So,
what's
coming
with
the
support,
the
support
for
altair
is
actually
the
first
major
version
increase
of
prism,
so
we're
going
to
be
releasing
the
v2
of
our
of
our
e2
client.
You
know
this
will
contain
full
support
for
the
altair
hard
fork
transition.
We
have
a
new
slash
implementation,
which
is
really
cool,
and
it's
able
to
just
really
you
know,
help
help
improve
the
security
of
the
network.
You
know
and
anyone
can
run
it,
and
you
know
just
really
good
to
have
a
lot
more,
better
documentation
and
outboarding.
B
You
know:
we've
been
recently
working
a
lot
with
stakers
really
understanding
what
is
the
experience
of
becoming
a
validator
in
youtube,
and
I
think
the
the
folks
at
eatstaker
have
been
really
instrumental
in
this
and
we're
going
to
be
engaging
with
them
more.
Actually,
we
have
a
new,
a
new
team
member
james
that
just
joined
us.
That
is
focusing
a
lot
on
ux
and
we,
you
know
we
really
want
to
revamp
this
over
the
coming
weeks.
Aside
from
that,
we
have
full
support
for
the
ethereum
consensus
standard
api.
B
B
So
what
are
some
of
the
unique
challenges
that
you
know
we've
faced
throughout
this
journey?
This
is
a
bit
more
involved
in
the
code,
but
in
general,
hard
forks
require
using
kind
of
generic
functions
for
processing
different
kinds
of
data
structures.
So,
for
example,
you
know
like
the
way
that
a
block
looks
on
on
on
the
chain
is
different
before
the
fork
and
after
the
fork
like,
if
you
think
about
hard
forks
on
ethereum
proof
of
work.
B
For
example,
like
you
know
the
the
structure
of
blocks
and
transactions
change
before
eiep
1559
and
afterwards
right.
So
how
do
you
do
that
in
a
way
that
is
maintainable
and
efficient
right?
It
sucks
that
you
would
have
to
duplicate
everything.
Is
there
a
better
way?
The
language
of
choice
for
us
go
does
not
support
generics,
so
this
is
really
really
unfortunate.
It
makes
things
like,
probably
10
times,
100
times
more
difficult
for
a
lot
of
things
that
we're
building.
B
You
know
other
languages,
it's
very
easy
to
write
a
function,
that's
like
hey
process,
a
block,
and
then
you
pass
in
a
block,
and
this
block
is
a
generic
block
and
you
can
do
all
kinds
of
things
with
go.
You
can't
really
do
that
right.
So
how
can
we
do
this
in
a
maintainable
way
that
kind
of
is
extensible
across
hard
forks
right
as
an
example,
we
were
talking
about
earlier.
You
know
you
can't
really
do
the
above
and
go.
B
You
can't
really
have
a
function
called
process
block
that
just
takes
in
some
generic
thing
and
does
whatever
you
know.
Instead,
you
might
have
to
duplicate
your
logic,
so
you
have
a
function,
called
process
block
for
phase
zero
and
then
process
block
for
altair.
This
is
unfortunate
because,
if
you,
if
you
do
this
everywhere,
you
know
when
you're,
basically
more
the
more
code,
you
write
the
more
probability
of
bugs
that
you
encounter,
and
this
is
extremely
risky
right
so
like
we
need
to
find.
Possibly
you
know
better
solutions
than
just
duplicating
everything.
B
Basically,
we
would
need
to
rewrite
the
whole
spec
for
out
there
and
rewrite
the
whole
spec
for
phase
zero,
and
that's
that's
not
good,
so
something
you
can
do
is
you
can
use
interfaces
and
go
which
are
kind
of
like
you
know,
they're,
not
exactly
generics,
but
they
allow
you
to
specify
behavior
of
certain
data
structures,
so
you
can
define
a
beacon
block
interface.
That
is
then
able
to
kind
of
do
certain
things
you
know,
so
it
has
a
slot
function.
B
B
B
So
that's
kind
of
one
way
that
you
can
get
around
the
problem,
but
it's
still
something
very
tricky
to
solve
another
way
you
can
get
around
the
the
trickiness
of
no
generics
and
go
especially
when
dealing
with
things
like
hard.
Forks
is
use
code
generation,
so
code
generation
is
a
very
popular
and
very
powerful
method
in
go.
Basically,
there
are
a
lot
of
commonalities
between
data
structures
that
you
want
to
that.
You
basically
want
to
want
to
ensure
they
work.
B
You
don't
want
to
have
to
write
it
by
hand,
so
using
generated
code
to
say
like
okay.
How
do
you
turn?
How
do
you
encode
a
beacon
block
into
bytes?
You
know
we
can
generate
code
that
does
that
both
through
phase
zero
and
for
altair,
so
code
generation
is
our
friend
for
dealing
with
a
lack
of
generics
here
and
that's
been
extremely
helpful
for
us
and
there's
really
a
lot
to
unpack
from
looking
at
the
changes
in
prison
regarding
out
there.
B
That
would
encourage
everyone
to
kind
of
look
at
our
repo
and
and
if
you're,
you
know,
if
you're
interested
in
this
sort
of
stuff,
you
know,
there's
there's
been
a
lot
of
discussions
and
design.
You
know
that
went
into
into
prism's
altair
changes,
so
yeah
I'll
pass
it
over
to
terence
about
how
prism
is
handling
the
fork
itself.
C
Yep,
let's
go
so
that
rose
said.
There's
many
solutions
to
this
problem
right
and
the
first
solution
is
that
you
just
copy
and
paste
everything.
So
in
this
example,
you
have
your
state
transition
function,
which
is
using
the
old
phase,
0
block,
and
then
you
copy
paste,
and
now
you
have
this
new
attitude
state
transition
for
a
tear.
That's
passing
in
the
attack
block
right,
so
basically
for
every
new
type.
We
copy
all
the
methods
that
are
used
to
process
block
and
manually
for
each
type
and
mainly
for
each
type
right.
C
So
what
are
the
advantage
there?
So
the
advantage
here
is.
This
is
very
easy
to
do
right,
just
copy
paste,
copy
paste
and
copy
paste,
but
there
are
probably
more
disadvantage
right.
The
disadvantage
is
means
that
when
you
modify
any
code,
you
have
to
modify
all
the
copy
and
paste
the
code.
Imagine
you
find
the
bug
and
then
you
have
to
make
sure
you
submit
fixes
for
every
single
copy
paste
out
there
right.
That's
a
lot
of
boilerplate
code
and
it's
very
hard
to
maintain
right.
Imagine
you
stake
your
32
years
using
prison
validators!
C
That's
about!
Like
hundred
thousand
dollars
and
then
you
and
then
you
look
at
our
copies
and
then
and
then
and
then
majority
of
it
it
just
copy
paste,
I
mean
that's,
probably
not
gonna
make
you
feel
good
right.
So
the
next
solution
and
the
next
type.
Please
is
essentially
so
that's
the
typo.
It's
not
copy
all
the
functions.
Many
very
tail
tears.
Sorry,
you
can
go
back
so
solo.
So
so
that's
that's
like
so
what
I
mean
yeah.
So
what
I
mean
here
is
basically
abstract
the
blog
interface
type
right.
C
C
So
it
gives
developer
the
field,
flexibility
where
they
can
write
the
code
in
such
way
that,
as
long
as
they
satisfy
the
interface
and
they
can
use
the
code
within
the
function
right
and
then
so
there
so
the
advantage
here
is
that
you
reduce
any
duplication,
don't
need
to
duplicate
code
anymore
right
and
then
multiple
methods
could
be
reused
for
different
types
right.
And
then,
if
you
look
at
this
example
right,
so
you
have
this
speaking
block
interface
and
then,
as
long
as
you
return
a
beacon
block,
and
then
you
return
a
signature.
C
You
can
use
that
interface
and
same
goes
for
beacon,
block
body
as
soon
as
you
return
attestations
as
long
as
you
return
deposits,
and
then
you
can
reuse
it,
so
the
code
doesn't
care
as
as
long
as
you
implement
these
getters
or
status
right.
So
you
can,
you
can
think
of
phase
zero
block
and
then
the
and
then
the
attack
block
and
even
in
the
future,
like
the
merge
block
as
soon
as
the
satellite,
this
interface
and
they
can
be
reused.
So
that's
like
right
so
so
to
satisfy
the
interface
right.
C
The
physical
block
needs
to
implement
this
getter
and
center
right.
So
now
so
right
now
you
have
this
atari
sign,
beacon,
block
function
and
then
essentially
wraps
around
the
physical
block,
and
then
you
implement
the
signature
and
then
the
block
method.
Right.
When
you
do
those
two,
then
you
can
be
sure
that
it's
satisfied
interface
and
next
slide
right
and
then
so.
This
is
just
a
constructor,
a
transstructure,
meaning
that
if
you're
passing
in
the
physical
block,
the
tail
physical
block,
you
actually
hear
your
returning
interface.
C
So
as
soon
as
we
do
this
step,
then
you
can
passing
in
that
interface
into
the
function.
So
that's
very
neat,
in
my
opinion,
next
slide
right
and
then
we
also
we,
I
think
something
that
we're
doing
a
lot
better
than
day
zero
is
that
we
are
greatly
improving
our
code
quality.
I
mean
we
have
always
been
on
it
for
code
quality.
B
Briefly
about
this
software,
thanks
yeah,
so
so
this
one,
you
know
we
care
a
lot
about.
Basically
following
really
really
strong
software
design
principles
right.
Some
of
the
major
things
that
we're
trying
to
do
is
really
really
try
to
enforce
this
in
our
in
our
code
and
and
a
very
popular
kind
of
paradigm.
B
To
think
about,
designing
software
is
called
solid,
so
at
a
high
level
kind
of
what
it
stands
for
is
you
know
your
function
should
have
single
responsibilities,
so
you
know
you
should
have
a
function
that
does
something
and
actually
ends
up
doing
something
else,
or
does
multiple
things
that
you
don't
want
that
you
don't
want
to
happen.
You
should
be
able
to
leverage
interfaces
and
make
basically
simplify
your
code
a
lot
more
and
you
should
depend
on
abstractions
on
implementation,
details
right.
B
This
is
kind
of
what
we
were
talking
about
with
interfaces
where
you
know
our
functions.
They
they
take
in
this
block
interface.
That
defines
what
a
block
is,
but
it
doesn't
really
but
it.
But
it's
it's
not
really
the
concrete
you
know,
phase
zero
block
or
altair
block.
So
really,
just
following
these
design
principles
has
been
really
really
crucial
for
us
to
deal
with
the
altair
hard
fork
and
a
lot
of
a
lot
of
a
lot
of
our
writing
and
our
rationale
is
kept
in
our
hack
and
b.
B
So,
if
you
go
to
hackandio
at
prismatic,
labs
you'll
see
a
lot
of
information,
especially
this
design
principles
document
that
we've
been
working
on
for
the
past
few
past
few
past
few
weeks
cool.
So
you
know
one
more
thing
is
you
know
we
care
a
lot
about
having
like
cleaner
validation,
pipelines
right.
One
of
the
biggest
risks
for
for
ethereum
nodes
in
general.
Is
the
peer-to-peer
networking
entry
points
right?
Every
node
is
kind
of
the
server
that
is
in
an
open
network.
B
B
We've
been
focusing
a
lot
on
on
refactoring
and
simplifying
our
validation
pipeline,
so
they
are
extremely
legible
and
anyone
can
anyone
you
know
can.
Can
we
go,
can
understand
what's
going
on
in
this
case,
you
know,
say
you
want
to
validate
a
block.
You
know
you
can
validate
that
it
has
a
valid
signature.
It's
canonical
it's
from
a
valid
peer
and
basically
following
the
specification
line
by
line,
and
that's
been
extremely
helpful
for
us
in
in
ensuring
safety
in
our
previous
last
few
releases,
so
yeah,
terence.
C
Next
one
so
we're
just
looking
at
code
leave
and
so
like
raw
said,
and
then
I'm
gonna
reiterate
this
right,
we're
always
open
for
new
contributors.
Whether
you
want
to
do
prototype
full
time
just
want
to
take
code.
You
want
to
update
our
stuff
I'll,
be
more
than
half
we'll
be
more
than
happy
to
guide
you.
So
so
there
has
been
probably
over,
like,
I
would
say,
10
000
to
20
000
of
new
code
that
has
went
in
since
a
tear
because
of
all
the
changes
and
and
because
of
all
the
force
logic.
C
C
And
then
all
the
networking
is
under
our
sync
and
p2p
package,
and
this
is
where
that
raul
said
before
that.
This
is
where
you
prevent
dos.
This
is
where
you
ensure
network
and
discouraged
the
bitcoin
node
can
discover
each
other,
and
then
they
can
coordinate,
which
gaussian
network
to
be
on
next
slide
and
then
validator
right.
This
is
the
fun
one.
This
is
where,
as
a
validator,
now
you
have
to
do
more
duty.
C
You
have
to
submit
sync
committee
message,
synchronic
contribution,
so
this
is
where
the
validators
implements
the
rpc
client
service,
and
this
is
where
to
look
at
if
you're
interested
at
the
validated
side
of
things
next
slide
and
then
optimization.
So
so
we
do
have
optimizations
behind
our
peer
implementation,
because
otherwise
it
may
be
a
little
slower.
C
So
if
you're
into
optimizations,
you're,
king
and
you're
king
at
looking
or
or
or
finding
out
how
we
do,
these
optimizations
check
out
our
sync
committee
cache
and
the
active
balance
cache
and
those
are
the
locations
for
it
next
slide
and
then
and
then
last
one
and
last
but
not
least,
the
bitcoin
state
right.
So
we
have
this
patient
state
speech
and
state.
Three,
and
essentially
we
can
stay,
is
cash
behind
it.
So
we
we
do
like
we.
C
So,
if
you're,
looking
at
stage
three
caching,
how
we
implement
the
settings
and
getters
and
state
v2
package
is
the
place
for
that
and
then,
of
course,
the
new
spat
test
so
shout
out
to
the
ethereum
foundations
or
the
research
implementers
they
implement.
This
awesome
spat
test
which
we
passed
as
of
today,
and
these
spare
tests
are
under
sweat,
test
maintenance,
folder.
B
Cool,
so
how
do
you
actually
test
the
hard
fork
and
make
sure
that
it
works
right?
You
know
so
when
you,
when
you
write
software,
the
mo
you
know
there
are
all
kinds
of
different
tests
you
can
have.
You
can
test
out
your
individual
functions
like
let's
say
you
have
a
function
that
takes
a
square
root
like.
Can
you
check
that
it
actually
computes
the
proper
square
root
right?
These
are
unit
tests
very
straightforward
and
typically
everything
should
be
unit
tested.
B
You
also
have
integration
tests
that
kind
of
cover
like
multiple
components
together
right
so
like.
Oh,
you
know,
if
I
receive
a
block
from
p2p,
can
then
can
it
then
be
processed
into
the
blockchain
and
stuff
like
that?
You
know:
that's
a
little
bit
more
involved,
and
you
know
you
if
you,
if
you
have
all
these
different
tests,
that's
pretty
good,
but
it's
not
good
enough.
Something.
That's
really
important
is
being
able
to
understand
how
this
will
perform
in
a
real
environment
and
how
you
know.
B
Basically,
how
will
it
work
if
you
actually
launch
a
beacon
node
if
you
send
out
deposits,
if
you
run
a
validator,
if
you
run
an
e1
node?
If
you
do
all
these
things,
just
like
in
the
real
in
the
real
in
the
real
world,
you
know:
does
the
code
perform
as
expected?
Something
that
we
take.
You
know
like
basically
great
pride
in
is,
is
basically
testing
in
our
in
our
m2m
test
suite.
B
But
before
this
I
guess
something
that
is
something
that
we
have
is
we
have
this
fork
transition
code,
so
it's
like
we
always
check.
Are
we
able
to
upgrade
to
altair?
If
so,
then
we
perform
this
function,
that's
just
called
upgrade
to
altair,
there's
quite
quite
a
few
things,
but
the
most
important
thing
is
that
end-to-end
testing
is
critical
in
prism.
You
know
the
in
the
client.
We
actually
have
a
full
end
to
end
testing,
suite
of
beacon,
node,
validators
and
guest
notes
on
every
single
call
request.
B
So
what
this
means
is
that
it
actually
spins
up
a
beacon,
node,
a
guest
node
from
genesis
it
like
it
actually
creates
a
deposit
contract.
It
sends
deposits
it
activates
validators
and
it
runs
prism
as
long
as
we
want
right.
So
it
does
all
these
things.
You
know
to
simulate
the
real
environment,
and
this
happens
on
every
single
pull
request
we
make
with
a
repository.
B
It's
not
like.
You
know,
we
have
a
test
net
and
then
we
try
things
on
the
test,
and
now
this
actually
runs
from
scratch.
Every
single
time
we
push
code
up
to
github,
so
we're
really
proud
of
our
end-to-end
test
suite
and
some
of
the
things
that
we
use
it
for
are
very
important.
We
always
we
have
these
evaluators.
That
are
very
easy
to
add.
So
basically
we
say:
okay,
I
want
to
evaluate
the
following
things.
We
want
to
make
sure
that
validators
are
participating,
that
the
chain
finalizes.
B
You
know
that
we
can
voluntarily
exit
the
validators
you
know
can
can
can
perform
the
fork
transition.
So
we
have
all
these
different
evaluations
that
we
can
then
verify
against
our
end-to-end
test
suite.
So
this
is
a
way
that
we
can
really
ensure
that
the
fork
transition
goes
smoothly
right.
To
give
you
guys
a
very
simplified
version
of
what
an
evaluator
looks
like
this
is
just
a
very
straightforward
tech.
There's
a
lot
more
there's
a
lot
more.
That
actually
happens
here
and
a
lot
more.
You
can
do
here,
but
basically
this
evaluator
says
hey.
B
I
want
to
check
that
a
fork
transition
actually
occurs.
So
what
it's
going
to
do
is
it's
going
to
be.
You
know
getting
a
block
after
the
after
the
the
fork
epoch
and
it's
going
to
say:
hey.
Did
you
give
me
an
outer
block
or
a
phase
zero
block?
If
you
gave
me
a
phase,
zero
block,
that's
wrong.
We
should
have
already
performed
the
fourth
you
know
after
that
epoch.
You
can
do
a
few
other
things.
After
that,
you
can
verify
certain
things
about
participation,
check
that
the
chain
continues
finalizing.
B
So
our
end-to-end
test
suite
has
saved
us
many
many
times.
You
know
it's
a
way
to
ensure
that
very
critical
things
never
break,
and
you
know
that's
something:
we've
been
we've
been
putting
a
lot
of
effort
into
right
cool
so
how
to
contribute.
So,
if
you're
wondering
about
how
to
get
started,
there's
a
lot
of
room
to
help
with
reviewing
code
by
cross-checking
against
the
specification.
B
So
there's
the
e2
specs
repo,
and
you
can
compare
that
with
our
changes
to
the
altair
fork
in
the
prism
itself,
you
can
find
gaps
in
testing
right,
so
unit
tests
are
very
important.
You
can
try
to
run
tests
using
our
the
go
test
coverage
tool
and
you
might
realize
that
some
packages
could
use
a
lot
more
love
a
lot.
A
lot
more
testing
find
ways
that
our
code
is
confusing
and
bring
it
up.
You
know
if
you're,
if
this
doesn't
make
sense
to
you
if
this
is
if
this
is.
This
is
weird.
B
If
this
isn't
like
the
way
that
you
should
write,
go
code
then
tell
us
and
and
tell
us
the
rationale
of
why
you
think
that
is
and
contribute
to
open
issues
on
github.
You
know
we're
more
than
welcome
you're.
More
than
welcome
to
help
to
you
know
to
join
in.
We
will
help
you
so
we're
also
hiring
we're
hiring
for
devops
and
security.
Engineer
positions
come
join
us.
You
know
we're
on
the
brink
of
one
of
the
largest
accomplishments
in
ethereum,
which
is
shipping
proof
of
stake
to
the
entire
network.
B
A
Thank
you
so
much
for
this
detailed
presentation.
I
mean
you
already
have
answered
a
few
questions
that
was
listed
in
my
sheet,
I'm
glad
that
it
got
answered
and
we
have
room
to
talk
different
topics
as
well.
First,
I
would
like
to
open
the
floor
for
our
friends
from
the
eat
sticker
community
to
go
ahead
with
their
questions.
D
D
We
had
suggested
that
community
members
who
are
interested
in
running
a
slasher
maybe
do
that
on
a
separate
piece
of
hardware
from
their
validator
because
of
the
hardware
requirements
is
the
refactored
slasher,
something
that
might
change
that
or
or
is
it?
Is
it
still
something
that
you
would
want
to
consider
running
on
a
separate
machine
yeah?
It's
probably
a
good
idea
to
run
on
a
separate
machine.
B
You
know,
and
just
like
you
know,
we're
releasing
a
new
slasher,
doesn't
mean
that
we're
releasing
this
like
perfect
new
thing.
It's
it's
also
gonna,
it's
gonna
be
a
new.
It's
gonna
be
new,
so
they're
they're,
you
know
they're
gonna,
develop,
there's
gonna
be
bugs
and
new
things
to
improve,
but
we're
confident
that
it
will
be
a
lot
better
at
resource
use
and
like
previously
the
old
one
would
like
it
would
not
do
well
in
periods
of
chain
instability.
So
you
know
we're
really
proud
of
kind
of
what
we
put
together
and
yeah.
D
Well
and
slasher:
it's
always
kind
of
a
thankless
job
anyway,
because
you
kind
of
hope
it's
never
used,
and
then
you
know,
apparently
it
is
used
pretty
often
so.
Obviously
I
you
know
I
have
been.
I've
been
screaming
the
past
few
days
about
the
need
to
improve
client
diversity
and
you
know
obviously
we're
on
the
same
team.
B
B
Basically,
it
would
ideally
allow,
for
example,
something,
like
you
know,
people
to
use
prism
as
a
failover
beacon,
node,
that's
still
not
something
that
is
fully
rolled
out
yet,
but
that's
a
first
step
you
know
like
having
having
full
support
for
the
standard
api
is
going
to
be
really
huge
aside
from
that
I'll
pass
a
return.
So
if
you
have
some
more
ideas
here,.
C
Right,
I
think,
asides
from
e2
api.
Our
slash
scene
exchange
is
fully
compatible,
so
you
can
actually
import
slashing
protection
that
steam,
if
we
go
from
lighthouse
or
maldives,
to
prison
validator,
or
vice
versa,
that
you
can
import
the
station
protection
history
and
that's
very
important
and
that's
being
implemented
and
something
on
the
higher
level.
It's
I
think,
it's
more
important
to
like
level
the
playing
field
by
level.
C
The
playing
field
I
mean
like
what
features
are
people
looking
for
because,
like
a
lot
of
times,
I
go
into
the
discord
or
like
reddit
I
was
and
then
and
then
I
always
ask
what
people
want
right
and
people
and
then
most
of
and
you'd
be
surprised.
A
lot
of
people
want
windows
and
then
a
lot
of
people
want
windows,
binary
and
a
lot
of
people
want
to
ui
and
stuff.
Like
that.
D
Yeah,
I
I
appreciate
you
so
that
everyone,
everyone
that
I
talk
to
well,
that's
not
true,
most
people
that
I
talk
to
want
a
windows,
implementation
for
other
clients
when
I,
when
I
grab
them
and
shake
them.
Why
aren't
you
trying
other
clients?
It's
because
there's
no
windows
implementation,
so
I
do
acknowledge
that
it
is.
It
is
in
many
ways
an
opportunity
for
other
clients
to
to
step
up
to
that
plate.
My
final
question
is
more
about
alter
general
will,
will
validators
expect
any
different
operation?
C
Nope,
it
is
the
same
thing:
it's
seamless
if
you're
running
beacon,
no
validated
combo.
You
just
have
to
upgrade
your
software
before,
and
that
is
it
that
is
it
and
then
we're
doing
a
very
careful
job
to
make
sure
like,
even
for
monitoring
from
the
ui's
perspective
that
nothing
breaks
off
because,
like
you
don't
want,
we
don't
want
to
scare
people
right
saying
like
that.
C
You
monitor
something
and
then
all
of
a
sudden
your
participation
dropped
to
zero
and
that's
because
of
using
the
right,
endpoint
or
or
or
that's
because
of
the
endpoint
did
not
consider
a
pair.
So
we're
doing
an
extra
careful
job
on
that.
But,
from
the
end
user's
perspective,
nothing
will
changed
the
most.
B
Important
thing
is:
we
definitely
need
to
get
word
out
there
that
people
need
to
upgrade
well
in
advance.
You
know
they
should
so.
I
think
I
think
a
lot
of
I
think
we
are
looking
for
end
of
september
v2
release
for
prism,
so
that
gives
probably
around
two
or
so
a
little
bit
over
two
weeks
before
the
fork.
So
that's
really
important.
We
just
need
to
you
know,
put
that
everywhere
share.
It
everywhere,
upgrade
your
nodes.
You
know
ever
so
that's
similar
to
what
we
do
with
week.
One.
D
D
B
D
D
B
E
That
is
really
cool
yeah.
So
I
was
writing
down
some
questions.
As
you
went
through
and
you
you
guys,
did
an
awesome
job
really
answering
most
of
them,
but
I
guess
from
the
testing
side
and
superfiz
was
saying
that
I'm
gonna
ask
some
hard
questions.
Maybe
I
don't
think
everyone
has
a
hard
cards,
maybe
slightly
more
software
focused
but
from
the
testing
side,
like
obviously
you're
coordinating
a
lot
with
the
other
client
teams.
How
much
of
your
either
testing
speech
or
testing
procedures
and
voting
standards
can
be
and
are
shared
across
teams?
C
Right
so
at
the
at
the
minimal
we
have
the
e2
spread
test.
It's.
This
is
a
cross-climb
battery
test.
So
that
ensures
that
if
you
pass
the
spare
test,
all
the
clients
could
talk
to
each
other.
At
the
most
happy
cases,
it
means
that
all
the
clients
can
run
state
transition
the
same
they
can
serialize
and
deserialize
objects
the
same
so
but
then
we
cannot
count
on
that
right
because,
like
there
may
be
testing
gap,
it
is
getting
a
lot
better,
though
so
shout
out
to
alex.
C
But
I
I
do
want
to
bring
other
clan
into
this
nbn
test,
so
we'll
have
tag
who
will
have
lighthouse
and
more
into
the
entrance
and
therefore
we
can
help
each
other
to
catch
bugs
that
that
may
not
happen
if
just
a
single
client
entrance
and
that's
something
that
I
I
do
really
want
to
work
on.
Yeah,
oh.
B
I
just
want
to
say
that
that's
a
really
actually
really
good
suggestion
to
you
said
like
to
make
it
accessible
to
other
teams
if
it
can
be
extracted
from
prism
in
a
way
and
like
made
it
so
that
yeah
like
this
end-to-end
test,
it
could
be
easy
for
the
other
teams
to
also
run
and
include
their
own
stuff
in
there,
and
it's
like
a
common
suite
of
tests
that
everyone
runs.
I
think
that'll
be
really
cool.
E
Yeah
right
on,
like
I
was
just
thinking
like
the
end-to-end
test,
I
mean
they're,
interacting
with
the
client
and
the
validator,
presumably
with
the
same
interface.
So
in
theory,
it
should
be
able
to
be
used
for
multiple
different
clients.
On
the
other
hand,
I
was
wondering
if,
like
test
decentralization,
makes
sense
as
well
so
like
having
different
implementation
tests
in
case
there's
like
a
flaw
in
the
testing
speed.
There's
also
like
good
to
have
diversity
in
there.
E
B
C
Yeah,
I
can
go
first
so,
like
I
do
work
on,
I
I
do
work
on
a
company
for
like
a
good
eight
years
in
my
career,
to
start
up
right.
So
the
biggest
difference
is
that
the
difference
between
core
closed
source
and
open
source
right
just
when
you,
when
you're
working
on
a
company
like
facebook,
google
right
most
of
the
things,
are
core
source
and
and
the
what
you
touch
right.
It's
like
there.
C
You
have
to
sign
like
an
mba
and
then,
if
you
disclose
some
information,
you
will
probably
lose
your
job
and
you
and
then
you
probably
get
fired,
that's
pretty
bad
right
and
then
so
every
every
person
you
interact
with
is
likely
in
your
office.
It's
probably
some
one
can
talk
to
you
like,
and
then
you
have
more
of
a
hierarchy
structure.
You
report
to
a
manager,
manager
reports,
the
director
that
indirectly
reports
to
the
vp
and
so
on,
right
and-
and
I
would
say
this
is
very
different
in
a
way-
it's
very
exciting
and
refreshing.
C
For
me,
I
think
first
thing.
First,
everything
is
in
the
open
right
like
like
every
work.
I
do
you
can
see
it
like
when
I
push
a
code.
If
it's
shitty,
you
can
tell
me
you
can
see
it,
but
everything
that
you
do
is
in
the
open,
and
second
thing
is
that
and
then-
and
the
second
thing
is
that
you
can
interact
with
the
developers
more
openly
like
today.
I
can
knock
on
danny
ryan's
store,
be
like
hey.
C
What
is
this
right
instead
of
like
you,
can
never
knock
on
someone
that
you
can
never
unlock
from
someone
that
wants
a
google
be
like
hey?
How
come
the
search
engine
does
support,
so
you
have
this
more
close
interaction,
so
I
found
that
really
cool,
and
then
I
and
then
the
last
thing
for
me
was
just
like
you
get
to
work
with
people.
There
are
all
over
the
world
right.
We
have
like
half
our
team
in
the
us.
We
have
a
team
in
europe
and
asia
and
stuff
like
that.
It
is
a
global
operation.
C
E
That's
awesome:
yeah,
it's
really
cool.
It's
yeah!
I
totally
like
what
you're
saying
about
being
like
an
open
source
project
and
accessibility
being
able
to
talk
to
different
people.
It's
cool
earlier.
You
were
talking
about
increasing
your
coding
standards
and
I
imagine
in
some
cases
like
you
might
need
to
be
addressing
technical
debt
insurance
releases.
Things
like
that.
How
do
you
decide
between
new
teacher
development
and
addressing
technical
debt
when
deciding
on
what's
going
to
go
into
a
release.
B
Yeah,
you
know,
I
think
previously
we
used
to
cut
some
corners
and
that's
that's
you
know,
that's
that's
a
mistake
that
we
think
we
could
have
improved,
and
by
by
that
I
mean
that
you
know
we
would
have
this
with
a
feature
that
really
needed
to
go
in.
We
would
try
our
best
to
really
like
you
know,
review
it
and
whatnot,
but
we
would
end
up
merging
kind
of
like
these
large
pull
requests
with
a
lot
of
code.
B
You
know
and
like
we
changed
that
practice
like
we
basically,
if,
if,
if
we
think
that
a
feature
is
important
and
it
is,
it
is
very
critical,
we
take
a
step
back
and
we
actually
you
know
we,
we
we
don't
compromise
on
time.
We
take
our
time
and
we're
like
no
we're
gonna
like
break
this
up
review
it
carefully
and
work
on
changing
it.
You
know
to
how
it
could
be.
You
know.
B
Sometimes
you
see
some
coding,
like
oh
we're
kind
of
in
a
relationship
this
feature,
but
then
you
know
the
code,
the
code
standards
and
the
code
quality
are
not
up
to
up
to
up
to
what
we
all
expect.
You
know
we
don't
compromise
on
that
and
we
all
take
a
step
back.
We're
like
let's
redesign
it
from
first
principles,
and
you
know
we
write
a
lot
of
design
documents
so
for
those
unfamiliar
like
design
documents
are
basically
these
kind
of
like
this.
B
They
can
be
like
these
one
pages
or
two
pagers
that
are
like
you
know,
give
us
a
background.
Just
share
background
of
like
what
this.
What
this
problem
is,
you
know
what's
the
current
solution,
what
are
what?
What
are
you
suggesting?
What
are
some
alternatives
and
we
kind
of
flesh
things
out?
We
talk
with
the
team,
we
have
design
review
meetings,
so
we
we
discuss
and
we
try
to
all
be
on
the
same
page
about
how
to
do
something.
B
So
lately
you
know
we,
you
know
we
put
a
lot
more
effort
on
that
and
a
lot
more
design
first,
rather
than
writing
the
code
first,
especially
for
altair,
you
know,
which
is
why
it's
been
taking
us.
You
know
longer,
I
would
say
than
other
client
teams
and
other
other
other
folks.
You
know
we
have
some
unique
challenges
and
go,
but
also
we
took
the
time
to
address
some
technical
debt
because
we
think
it's
worth
it
and
we
think
that
it's
it's
worthwhile
for
security
right.
E
B
For
deciding
when
to
launch,
I
think
that's
probably
more
like
something
that,
like
danny
ryan
and
the
ethereum,
you
know
research,
team,
kind
of
talks
to
all
the
different
teams
and
that's
kind
of
where
they're
at
and
gives
enough
buffer
for
the
community
to
be
ready
and
to
update
their
software
and
whatnot.
So
I
think
that
was
kind
of
more
like
a
consensus
decision
for
us
internally.
It's
about,
like
you
know,
basically,
what
worries
us
right,
it's
like
is
there
anything
that
is
scary.
That
worries
you.
That
makes
you
feel
uneasy.
B
Then
we
cannot
ship
until
we
fix
those
things
you
know
and-
and
I
think
that's
that's
that's
what
we
spend
a
lot
of
time
on
when
working
on
the
altair
changes
like.
Oh,
this
feels
fishy
and
like
like.
Should
we
do?
Should
we
leave
it
as
is
or
we
should
we
change
it?
No,
we
should
change
it
so
until
those
those
concerns
are
pretty
much
resolved,
I
think
you
know
we
were
not
ready.
I
think
at
this
point
we
have
finished
merging
in
all
the
different
outer
features
into
into
into
our
our
code
base.
C
C
B
And
we
have
a
promise
of
backwards,
compatibility
for
like
major
versions
of
prism
so
like
if
you're
on
v1
of
prism,
every
single
v1
release
will
work
for
you.
So
what's
been
really
crazy
is
like
we
had
a
few
people
come
into
our
discord
some
other
day
and
they're
like
hey,
I'm
having
some
issues
like
my
daughter's
money
what's
going
on
and
they
hadn't
updated
since
december
3rd
2020,
you
know
and
like
it
still
works.
You
know.
B
So
we
keep
this
backwards
compatibility.
We
don't
want
to
break
people's
setups,
especially
people
at
home.
You
know
on
every
release,
so
v2
does
have
breaking
changes
because
everyone
needs
to
upgrade,
so
we
might
as
well
take
advantage
of
that
time.
So
just
yeah
from
a
user
perspective,
you
probably
won't
have
to
do
much.
It'll
just
be
you
know,
an
upgrade
seamless
for
more
advanced
operators.
You
know
make
sure
to
definitely
read
the
release,
notes
and
what's
going
on
in
there
some
flags
and
some
configuration
things
might
have
changed
so
yeah.
D
Awesome
colfax
and
I
actually
share
the
last
question
in
general,
like
as
each
sticker
and
as
ech,
we
know
it's.
Our
role
to
you
know,
put
the
information
out
there
to
encourage
users
to
update
to
support
that
update.
Is
there
anything
else
the
community
can
do
to
to
provide
support?
Like
I
I
know
we
we
get
the
the
push
to
update,
but
what
else
might
community
members
offer
to
to
help
support
this
effort?.
B
I'd
say
like
finding
ways
to
like
you
know
something
like:
like
terence
mentioned:
they
were
working
on
improving,
like
the
ux
of
like,
but
being
you
know,
trying
to
install
the
software
and
become
a
validator
and
whatnot.
So
probably
having
more
conversations
around
that,
like,
I
think
something
could
be
interesting,
is
looking
at
all
the
different
clients,
documentation,
onboarding
right,
like
what
are
some
things
that
are
unclear.
B
I
think
we
would
benefit
a
lot
from
having
a
better
canonical
documentation.
By
that
I
mean
that
there
are
a
lot
of
really
amazing
guides
out
there.
Like
I
know
summer
asat
has
like
an
incredible
guy
that
is
successful
for
a
lot
of
stakers
right,
so
a
lot
of
people
end
up
using
those
third-party
guides.
You
know,
maybe
because
our
docs
are
not
that
great.
You
know
and
like
we
admitted
that
there's
a
lot
of
room
to
improve,
so
I
think
finding
ways
to
how
can
we
improve
documentation
like
the
client
teams
documentation?
B
D
Yeah
that
that
is
actually
a
great
idea.
It's
one
of
the
things
that
I'm
very
interested
in
is
multi-client
installers,
that
would
you
know,
kind
of
standardize
the
process
and
give
give
the
end
user
one
interface
and
from
there
they're
they're
choosing
you
know
what
do
I
want
to
run
yeah?
I
really
feel
like
that's
a
great
way
to
resist
tribalism.
D
There
is
you
know,
there's
significant
tribalism
for
prism
right
now
and
like
that
on
one
head
like
you
should
be
so
proud
of
that,
because
you
have
this
really
strong
community,
but
obviously
we
we
all
recognize
what
tribalism
leads
to
but
yeah.
So
I
I
do
love
the
idea
of
multi-client,
installers
and,
and
you
know,
a
single
interface
for
for
multiple
clients.
So
that's
a
good
idea.
Thank
you.
A
E
A
For
our
guest,
you
have
already
passed
the
difficult
phase
of
question
answers.
I
have
questions
which
are
relatively
lighter
and
like
not
directly
related
to
technical
stuff,
but
in
general
that
people
would
be
interested
into.
I
heard
that
you
guys
are
talking
about
documentation.
There
is
a
special
emphasis
on
documentation.
A
A
So
prism
is
a
leading
choice
of
validators
right
now
I
understand
the
team
has
come
a
long
way
on
clients
documentation.
Since
the
beginning,
though,
you
already
have
accepted
that
there
is
still
room
for
improvement,
I
assume
that
plenty
of
resources
are
available
to
set
up
a
node
for,
like
a
beginner's
point
of
view,
do
you
think
the
documentation
have
helped
users
getting
on
board
and
making
prism
the
number
one
choice
for
the
new
validators
or
what
is
the
reason
primary
reason
you
may
think
of.
B
You
know
it's
hard
to
say
it's
probably
a
lot
of
different
factors.
You
know
I
wouldn't
discount,
like
I
think
everyone,
but,
like
I'd,
say
all
the
different
teams
have,
I
would
say,
pretty
good
docs
and
they
all
put
a
lot
of
effort
into
that.
I
think
there
have
been
a
lot
of
community
based
guides
as
well.
That
have
been
really
helpful
and
I
like
a
lot
of
people
use
summer
asa
sky
for
windows,
which
probably
contributed
to
a
lot
of
validators
running
prism
on
windows
right.
B
So
you
have
a
lot
of
that
and
I
think
those
community,
like
community
home
board
guides,
make
a
big
impact
on
people's
choice
of
clients.
So
I
think
that's
something
that
you
know.
Definitely
I
know
the
eat
sticker
community
is
is
probably
keeping
in
mind
and
you
know
one
other
thing
is
that
it
seems
like
the
highest
impact
thing
for
client.
Diversity
is
to
really
work
with
the
hyatt,
with
the
with
the
large
institutions
or
large
large,
large
stakers
right
and
try
to
get
them
to
the
other
other
implementations.
B
I
think
I
think
at
that
point
we
will
start
to
see.
Hopefully,
more
of
a
balance
but
yeah
really
like
all
these
efforts
that
are
ongoing,
like
really
like
standardization
of
apis,
you
know
better
or
guides,
like
I
know,
superfood's
doing
a
lot
of
stuff
but
like
how
can
you
onboard
into
tekku
or
nimbus
or
whatnot?
So
really
those
things
will
have
impact
on
the
average
staker,
but
we
really
need
to
get
the
big
big
institutions
to
embrace
more
client
diversity.
A
B
No
we're
keeping
our
medium
we're
now
doing
like
kind
of
monthly
or
maybe
by
month,
like
bi-monthly
updates.
So
we
just
kind
of
you
know
our
bi-weekly
updates
used
to
become
super
in
the
weeds
and
very
specific,
and
you
know,
readership
was
very
low
after
a
while.
So
we
kind
of
wanted
to
keep
more
like
high-level
updates
released
every
month
on
medium,
so
we'll
still
be
using.
That,
for
sure
I
can
do
is
just
internal
for
our
our
team
documents,
but
even
those
are
open
to
the
public.
C
If
they
do
it's,
probably
that
one
or
two
cents,
it's
not
that
big
of
a
deal
right
then,
and
then
so
what's
important
to
look
at
is
that
how
easy
it
is
to
on
board
validator
from
a
client's
perspective
right?
So
if
we
can
do
that
and
make
all
the
clients
exactly
the
same,
I
think
the
client
diversity
will
be
better.
A
According
to
a
recent
survey
conducted
on
reddit,
we
found
that
about
50
percent
validated
run
the
eth1
chain
like
the
execution
chain,
and
there
has
been
a
dramatic
decrease
in
the
nodes.
Do
you
think
it's
because
of
the
change
that
we
are
going
to
expect?
Or
is
it
because
that
is
more
convenient
to
use
third-party
services.
C
So
I
think
for
now
it's
more
convenient
to
use
their
priority
service
because
there's
no
because
there's
no,
I
would
say,
incentivization
to
not
use
third
party
service
right.
If
in,
if
gives
you
a
free
endpoint
and
then
you
can
propose
block
fine,
your
validator
performs
fine,
it's
free!
Why
waste
the
extra
one
gigabyte
of
memory
that
you
have
in
your
computer
right,
but
there's
also
the
future
phases
right,
for
example,
the
merge
that
you
with
the
proof
of
custody.
C
You
do
kind
of
need
to
run
your
only
one
node,
unless
you
trust
infura,
with
your
data
and
stuff
like
that,
there
may
be
slashing
penalties
in
place
which
is
still
under
discussion.
So
the
end
goal
is
the
end.
Goal
is
essentially
to
have
everyone
run,
their
trusted
e1
setup,
and
I
do
believe
it's
important
that
we
educate
this
as
early
as
possible.
So
we
don't!
So
it's
not
all
of
a
sudden.
It's
like
hey!
You
have
to
run
your
effort
all
right.
If
we
can
educate
this
as
early
as
possible.
A
Right
and
for
the
users,
actually
the
validators,
what
are
your
thoughts
on
staking
pool
services,
like
recently
rocket
pool,
announced
that
they
would
be
launching
on
mainnet
on
october
6th?
Do
you
think
it
is
helpful
for
people
who
don't
understand
that
complete
mechanics
behind
the
staking
it's
just
easier
to
go
ahead
with
the
pool.
B
Yeah,
I
think
you
can
never
really
get
rid
of
that.
You
know
like
there.
People
want
different
things
and
there's
a
user
persona.
That
is
really.
You
know
really
just
cares
about
getting
getting
yield.
Undereath
and
you
know
if
there
is
enough
social
credibility
about
a
service
or
a
company,
they
will
use
that.
You
know,
and
I
think
that's
I
think
it's
important
to
support
those
people
like
really
you
know
they
they
stake
and
they
they
help
with
securing
the
network
by
adding
more
eth
to
the
validator
to
the
validator
registry.
B
So
yeah
I
mean
we.
We
personally
are
really
big
fans
of
things
like
secret,
shared
validators
and
things
such
as
like
staking
pools
that
aim
to
be
far
more
like
decentralized
and
whatnot
non-custodial.
You
know
we
think
those
are
important
right.
It's
you
know
it's
not
like.
Oh
that
sucks
everyone.
Everyone
should
run
their
raspberry,
pi
or
or
nuke
at
home
or
like
everyone.
Everyone's
everyone's
constraints
are
different.
B
I
think,
as
long
as
like
the
baseline
of
running
a
beacon
or
a
validator
at
home
is,
is
doable
for
and
like
it
is
an
option.
I
think
that's.
What's
real,
that's
what's
really
important,
knowing
that
there
is
a
thriving
community
of
homestakers
and
keep
you
know,
keeping
that
as
an
invariant
is
what
really
matters
and
also
secret
shared
validators
are
are
also
critical,
for,
I
would
say,
for
the
overall
security
and
and
ethereum
of
the
future.
A
A
C
So
atera
introduces
this
new
singh
committee,
the
concept
so
there's
this
one
more
reward.
That's
coming
out
right,
that's
the
security
reward,
but
there's
only
if
five
and
12
validators
get
to
participate
in
the
sync
committee,
and
so
the
chances
are
pretty
low
and
stuff
like
that.
But
if
you
do
participate,
consider
yourself
a
lucky
one.
I
I
want
my
military
to
be
in
it
every
single
day
and
stuff
like
that.
So
there
is
probably
more
insurance.
C
A
C
On
my
on
on
on,
like
our
team,
that's
been
working
on
this
day
and
night,
so
want
to
shout
out
to
nishan
for
making
all
the
spearheading
all
the
networking
changes
and
stuff
and
preston
and
casey
with
all
the
awesome
code,
reviews
that
have
been
doing
and
redick
with
all
the
api
changes
without
radic
we
wouldn't
have
interrupt
and,
of
course,
who
would
all
the
optimizations
and
james
new
hire
with
all
the
ui
stuff
that
he
has
been
working
on
so
yeah.
Thank
you
guys
for
all
the
hard
work.
A
Thank
you.
Thank
you,
terence
and
raul,
and
also
our
friends
from
each
community
for
taking
our
time
and
join
us
today.
The
team
is
doing
a
great
job
explaining
and
keeping
the
community
on
the
same
page,
and
I
hope
this
episode
would
be
helpful
for
our
current
beacon
chain
user,
as
well
as
the
future
validators
for
proof
of
ethereum.
A
On
this
note
for
all
our
youtube
viewers.
Thank
you
for
watching
this
episode.
We
have
provided
twitter
handles
of
the
cast
with
some
of
the
resources
on
prism
and
alter
upgrade
in
the
description
section
below.
We
will
also
find
the
link
to
earlier
episodes
that
we
recorded
with
few
other
contributors
of
beacon
sheen
on
the
topic
of
altair.