►
Description
Topics covered
-----------------------------
2:08 - Altair Beacon chain upgrade - Accounting reform
2:50 - Overview of Danny’s talk
4:20 - Penalty Parameter update
4:25 - Punitivity in EIP-2982
5:39 - Punitivity in Altair
9:25 - What does this mean for people who are staking from home especially those having no backups?
12:50 - Offline slashing (Penalties)
15:55 - How far are we from the max punitive?
17:19 - Inactivity score reform
17:22 - Inactivity score (Phase 0 vs Altair)
21:48 - Leak Demo
27:55 - Modifications to the consensus structure
29:46 - Sync Committees
29:54 - Validator duties
30:45 - New and modified duties
33:14 - Modifications to consensus structure - Sync aggregate
34:09 - Process sync committee
34:34 - Update sync committee
35:52 - Resources
36:10 - Vitalik presentation - Light client sync protocol
36:24 - How do light clients sync?
37:49 - How light clients keep track of finalized block?
43:41 - Some nuances
43:50 - Why do you commit to both the sync committee and the next sync committee?
46:00 - Where do you get the signatures?
47:35 - Do light clients listen to Gossips and light client aggregate channels themselves?
48:00 - Are full nodes required to provide wide access to light clients or is that also optional?
48:30 - What was the problem?
49:00 - Tasks for which light clients need full nodes?
50:21 - Finalized vs. non-finalized updates
53:25 - Getting non-finalized recent blocks
56:52 - Using Lightclients and embedding them in smart contracts, will they also be embedded inside the chain to give a smart contract awareness of the block state?
58:16 - Metrics
59:09 - Feel for Altair next steps in testnet
1:02:22 - Is the plan to test on the Pyrmont?
1:02:13 - Rewards & Penalties - are they finalized?
1:03:01 - What is that team considering to ensure validators are committed?
1:04:34 - Discouragement attacks
1:06:00 - Resources to educate about the upgrade
Resources:
-------------------
Danny's slides: https://drive.google.com/file/d/1NJUTaiNsN5sP9qyeNTY7O8qrWQezedGa/view?usp=sharing
Annotated specs: https://github.com/ethereum/annotated-spec/blob/master/altair/beacon-chain.md#beacon-state-mutators
Eth2 specs: https://github.com/ethereum/eth2.0-specs/releases
HF1 proposal - https://notes.ethereum.org/@vbuterin/HF1_proposal
Altair - Accounting reform with Alex Stokes - https://www.youtube.com/watch?v=KdhHJa2SEwY
Altair in Teku with Adrian Sutton - https://youtu.be/Kv643dgRmMI
Altair upgrade & roadmap (Prysm) with Raul Jordan & Terence - https://youtu.be/92BeeDr1Nhw
Beacon chain metrics & benchmarking with Parithosh & Leonardo - https://youtu.be/3xD2UyazRTE
A Brief History of Ethereum's Future with Ben Edgington - https://youtu.be/FlFKZR_ofSo
Beacon chain Proposals playlist - https://www.youtube.com/playlist?list=PL4cwHXAawZxoEw29YmqJtNoFaENUUAREn
Ethereum blockchain users and developers survey: https://docs.google.com/forms/d/e/1FAIpQLSeugRHv93fizew0zeqXFOOnQIbjbWnVHoThLJR3f3g6gVvXhQ/viewform
Follow at Twitter
-----------------------------------------------
Vitalik Buterin @VitalikButerin | Danny Ryan @dannyryan | William Schwab @William94029369 | Brent Allsop @Brent_Allsop | Pooja Ranjan @poojaranjan19
Check out upcoming EIPs in Peep an EIP series at https://github.com/ethereum-cat-herde...
Follow PEEPanEIP earlier episodes at https://www.youtube.com/playlist?list...
Contact Ethereum Cat Herders
---------------------------------------------------
Discord: https://discord.gg/tzYmDmF
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
So,
with
over
3000
applications
and
many
more
developers
working
on
ethereum,
it
is
the
largest
blockchain
network.
Upgrade
is
a
familiar
tool
for
those
who
have
been
in
the
space
for
a
while.
It
helps
maintain
the
security
of
the
team.
In
addition
to
useful
features
with
multiple
upgrades
planned
this
year,
the
community
is
expecting
a
lot
of
new
features
to
be
added
to
both
consensus
layer
and
the
execution
layer
team.
My
name
is
pooja
ranjan
and
I'm
going
to
be
your
host
for
today's
episode
on
altair.
A
Consider
responding
to
the
survey
if
you
interact
with
ethereum
blockchain,
run,
ethereum,
1.0
or
2.0
node
or
otherwise
contribute
to
blockchain
technology
in
general,
you
may
find
the
link
in
the
description
box.
That's
all
for
the
announcement
with
no
more
delay.
Let's
welcome
again
vitalik
and
dany.
We
had
you
in
earlier
episodes
talking
about
different
proposals.
B
B
Sweet
okay,
cool,
I'm
gonna,
share
my
screen
and
we'll
go
ahead
and
get
started
great.
Thank
you
for
being
having
me
at
peep
and
eat
again.
We're
gonna
talk
about
the
altar
beacon
chain
updates
and,
like
you
said,
alex
stokes
did
cover
the
accounting
reform.
I
highly
recommend
checking
that
out.
I
put
this
tiny
url
right
there.
If
you
want
to
snag
it.
B
I
also
put
this
picture
of
an
accountant
having
a
miserable
time
because
but
we're
trying
to
make
his
job
better
anyway,
accounting
reform,
a
set
of
changes,
internal
validator
participation,
accounting
and
a
bunch
of
like
related
rewards
to
make
things
more
efficient
and
also
more
incentive
compatible
check
it
out.
It's
a
good
call.
B
B
B
Is
it's
really
it's
the
first
time
that
this
new
consensus
mechanism,
the
beacon
chain,
is
being
upgraded
in
a
live
system
which
requires
client
teams
to
make
more
modular
structures
and
to
really
go
through
these
complex
motions
of
changing
the
rules
of
a
network
in
in
flight,
and
it's
very
important
that
we
do
this
in
an
isolated
context
before
we
do
the
merge,
which
is
doing
it
with
like
much
more
online
yeah,
the
execution
layer
where
all
the
applications
and
contracts
and
stuff
live.
It's
a
much
higher
stakes
upgrade.
B
B
There
was
a
proposal
to
reduce
the
punitivity
of
some
of
these,
like
tail
risk
penalty
parameters,
pretty
much
like
when
the
beacon
chain
is
not
acting
optimally
say
when
it's
not
finalizing
or
maybe
when
validators
are
slashed,
pretty
much
the
non-normal
operation
modes.
We
reduce
the
punitivity
of
these
parameters,
start
to
pretty
much
allow
for
the
ecosystem
of
new
validators
to
really
like
learn
how
to
do
this
stuff
and
and
de-risk
the
system
for
these
early
adopters.
B
So
quote
from
that
eip
for
the
initial
launch
of
phase
zero,
the
parameters
have
been
tuned
to
be
less
punitive
than
their
final
intended
values.
This
provides
a
more
forgiving
environment
for
early
validators
and
client
software
in
an
effort
to
encourage
validation.
This
early
higher
technical
risk
stage-
and
I
think
it's
it's
helped
in
here
and
there
we
haven't-
had
the
stretches
of
non-finality,
which
is
one
of
the
parameters,
but
we
have
had
a
number
of
hobbyists
and
institutions
receive
some
slashing
which
has
reduced
the
amount
of
that
penalty,
so
in
altair.
B
So
there's
the
girl,
she's
being
kind
of
punished,
she's
having
a
thing
finger
waved
at
her,
but
in
altair
the
penalties
are
being
ratcheted
up.
So
the
intention
in
2982
the
eip
was
to
turn
up
the
punitivity
to
maximum
intended
values,
but
instead
again
this
was
kind
of
a
compromise.
We
have
seen
some
slashings.
We
have
seen
some
non-optimality,
so
it's
kind
of
like
ratcheting
up
the
parameters
as
we
approach
the
merge
and
probably
the
post-merge
fork,
so
the
inactivity
penalty
quotient.
B
B
The
minimum
slashing
penalty
quotient
was
decreased
from
128
to
64.,
and
what
this
is
is
essentially,
if
you
get
slashed,
there's
a
minimum
amount
of
eath
of
a
fraction
of
your
eat
that
you
lose
as
kind
of
like
a
slap
on
the
wrist
and
you
get
ejected
from
the
valid
intercept.
This
was
in
the
normal
case,
32
over
128,
which
I
think
is
0.25
eath,
whereas
in
after
altair
it
will
now
be
0.58,
so
it'd
be
32
over
64..
B
B
B
So
if
ten
percent
of
the
values
are
slashed,
you
would
lose
twenty
percent
of
your
stake,
and
this
this
means
that
if
they're
you're
maximally
punished
now,
if
50
of
the
validators
at
any
time
are
slash,
the
intended
value
in
the
long
term
is
three
so
that
if
one
third
of
the
validators
are
slashed,
they
are
maximally
punished.
So
they
get
all
of
their
capital
burned,
and
this
is
because
that
is
the
minimum
required
amount
to
create
a
network
fault.
B
Even
though,
realistically
I
think
if
a
network
fault
was
created,
it
might
be
a
higher
number
than
that
so,
but
it's
moving
in
that
direction
so
really
simple
change.
These
are
the
addition
of
three
constants
and
the
utilization
of
those
new
three
constants
in
in
throughout,
rather
than
the
the
replacement
of
the
values
of
the
old
constants.
But
you
can
check
out
spec
if
you
want
to
look
into
it
more.
B
Okay,
sure
what
does
this
mean
for
people
who
are
sticking
at
home,
which
means
that
they
might
especially
like
hobbyists,
who
don't
necessarily
have
right,
backups
in
case
of
power,
and
things
like
that
right.
So
I
would
then
should
say
over
ninety
percent
of
slashings,
I
mean
over
95
percent
slashings
that
we've
seen
on
mainnet
are
actually
due
to
institutional.
A
B
Institutional
players,
having
way
too
sophisticated
of
setups
like
they're,
trying
to
do
extra
redundancy
and
having
double
signing
by
accident,
we
have
seen
a
small
number
of
validators
at
home:
do
redundancy,
setups
and
and
get
double
slash,
double
sign,
and
so
this
would
increase
the
severity
of
if
you
decide
to
get
clever
or
you
mess
up
somewhere
in,
like
your
cloud
deploy
and
you
deploy
to
two
clouds
or
something
by
accident.
In
that
you
would
likely
lose
point.
Five.
B
Eighth,
instead
of
point
two
five
eight
and
you
get
ejector
from
the
validator
set.
As
long
as
that
fault
is
not
correlated
this
third
point,
the
proportional
slashing
multiplier
really
isn't
going
to
affect
the
home
validator.
I
really
think
it's
this
middle
point
that
would
the
most
affect
the
home
validator,
but
I
do
want
to
augment
that
with
one
we've
seen:
fewer
and
fewer
home
validator
slashings,
I
think
the
educational
upfront
has
been
really
good.
We've
continued
to
see
institutional
players
get
slash.
B
We
actually
saw
a
slashing
today
with
an
institutional
player
that
used
a
highly
sophisticated.
When
I
say
highly
sophisticated,
I
mean
overly
complicated
redundancy
setup
that
caused
them
to
double
sign,
and
so
we
will
see
potential
issues
with
that
and
they'll
lose
a
little
bit
more.
Hopefully
it's
more
disincentive
there,
but
really.
I
think
this
is
also
augmented.
The
education
is
augmented
by
the
fact
that
increasingly,
each
client
team
has
been
rolling
out
doppelganger
detection
which,
by
default,
when
you
turn
on
your
client
it
it
doesn't
sign
messages
immediately.
B
It
waits
for
a
couple
of
epochs
and
four
goes.
A
couple
of
rewards
small,
very,
very,
very
small
amount
of
rewards
to
listen
to
the
network
to
see
if
anyone
is
signing
with
the
keys
that
they
control
and
if
they
see
anyone
signing
with
those
keys,
they
control
they
immediately
shut
down
and
say
nope.
This
is
unsafe.
I'm
not
going
to
sign
anything,
so
I
think
that
protection
is
actually
very
particularly
going
to
to
protect
hobbyists,
and
that
is
now
a
that
is
now
supported
in
nimbus.
I
believe
it
is
supported
in
prison.
B
It
is
to
be
in
a
release
soon
in
lighthouse
and
I
believe
it
might
be
in
tekku.
So
this
is
increasingly
a
very
standard
feature
that
I
think
is
going
to,
especially
for
the
hobbyist
who's,
not
doing
crazy
stuff
with
like
remote,
signers
and
modified
databases
and
stuff.
I
think
this
would
be
highly
protected,
so
it's
really.
If
there
was
a
leak
and
they
were
offline,
they
would
receive
a
little
bit
more
penalty
and
really
the
the
big
one.
B
C
B
B
A
validator
stands
to
lose
about
as
much
as
they
stand
to
make.
I
think
it's
actually
three
quarters
of
what
they
stand
to
make
they
can
lose.
So
if
the
rate
of
return
for
a
perfectly
validating
value
was
10
per
year,
an
entirely
offline
validator,
as
long
as
the
chain
was
finalizing,
would
lose
7.5
percent
over
the
year.
So
that
would
take
many
many
many
years
for
them
to
actually
leak
the
full
balance
and
and
even
get
to
the
16th
which
automatically
ejects
them.
B
This
penalty
quotient
is
related
to
when
the
chain
is
not
finalizing,
and
that
is
when
the
chain
is
not
finalizing.
Those
that
are
offline
have
an
increasing
an
increasing
penalty
such
that
the
chain
can
kind
of
self-heal
over
time,
such
that
the
offline,
the
offline
validators
that
are
offline
for
like
a
week
or
even
two
weeks,
begin
to
lose
an
increasing
amount
of
their
balance
so
that
the
online
portion
can
become
a
majority
and
begin
to
finalize
again,
and
so
this.
B
This
constant
is
in
relation
to
that
kind
of
failure
mode
in
a
sense
that
the
chain
is
consistently
not
finalizing.
This
dictates
the
growth
of
that
penalty,
and
so
in
the
normal
mode.
The
hobbyist
is,
this
does
not
affect
their
rewards
and
penalties,
and
they
could
still
be
offline
for
even
half
a
year
and
really
not
lose
that
much
money.
B
But
it's
in
the
event
of
one
of
this
kind
of
tail
risk
scenario
where
there's
some
major
global
event
and
network
partition
or
there's
some
sort
of
like
ongoing
dos
or
attack
where
the
chain
can't
finalize
and
that's
when
this
penalty
constant
comes
into
play,
and
essentially
it's
a
the
amount
that
you've
you've
lost,
grows.
Quadratically,
and
this
dictates
kind
of
the
the
rate
of
that
growth.
C
B
D
B
B
If
there
was
a
network
fault,
if
there
were
enough
slashings
to
create
a
network
fault,
people
are
maximally
punished
and
that's
really
getting
this
constant
from
one
to
two
to
three
and
so
very
likely,
so
that
the
post
merge
execution
layer
is
in
kind
of
a
maximum
safety
environment
at
the
merge
or
the
fork
after
the
merge.
This
would
be
this
stepwise
increase
to
maximum
punitivity
and
maximum
security
would
be
completed.
B
C
B
Cool,
I
am
going
to
continue.
Thank
you,
so
inactivity
score
reform.
We
kind
of
talked
a
little
bit
about
this
mechanism
and
there's
been
some
cleanups
to
allow
for
this
to
actually
have
a
better
recovery
and
for
it
to
be
more
fair,
so
in
phase
zero
really
there
was
one
score
fits
all,
and
this
led
to
a
couple
of
negative
scenarios
in
that
it
could
lead
to
a
choppy
recovery,
which
we
actually
saw
on
a
test
net.
B
I
can
talk
a
little
bit
about
that
and
it
punished
semi
online
validators
relatively
unfairly,
and
so
this
this
makes
it.
So
it's
actually
related
to
how
how
well
you're
actually
doing
I
mean
it
really
was
related
to
the
this
one
function.
Get
finality
delay
pretty
much.
If
it
wasn't
finalizing,
it
would
see
how
long
it
has
been
finalizing
and
punish
all
validators
who
are
offline
same
based
off
of
that
relative,
even
not
really
remembering,
if
maybe
the
epoch
before
they
were
doing
well
or
the
epoch.
B
Next,
they
were
doing
well
and
I
just
put
a
picture
of
fire
because
you
get
too
close
to
that
thing
and
everyone
gets
burned,
whereas
in
altair
there
is
a
score
added
per
validator.
So
we
had
this
like
one.
This
get
finality
delay
that
that
was
pretty
much
like
everyone's
global
score
as
to
has
to
offer
blindedness,
and
now
we
get
a
score
for
validators,
so
pretty
much
we're
tracking
on
a
per
validator
basis
in
a
single
array,
a
single
list,
so
there's
a
single
integer
per
value
per
validator
tracking.
B
How
well,
during
this
inactivity
leak
they
have
been
performing.
So,
if
they're,
if
they're
totally
offline,
they
perform
in
a
very
similar
way
today
because
they
get
their
their
score
is
essentially
this.
The
finality
delay,
if
they're
totally
online.
They
score
very
similar
to
today,
because
they
shouldn't
really
lose
anything
because
they're
they're
operating
optimally.
But
if
you're
in
the
middle
somewhere,
where
you've
been
online
here
and
there
they're,
the
indep
individual
score
of
the
validator,
then
is-
is
more
tailored
to
them.
And
what
what
happens
here?
B
Is
you
get
less
chance
of
a
finality
flip-flop
which
again
I'll
talk
about
in
a
second
and
you
get
you
get
a
more
fair
penalty
related
to
the
individual
validator
offlineness?
I
found
this
cool
image
with
a
quote
from
bill
gates.
It
said
life
is
not
fair,
get
used
to
it,
but
life's
a
little
bit
more
fair
after
altair,
so
I
want
to
talk
about.
There
was,
if
you
were
following
the
e2.
B
The
problem
with
this
mechanism
when,
especially
when
you're
dealing
with
a
global
leak
constant,
is
that
the
global
leak
constant
all
of
a
sudden.
It
forgets
that
it
was
in
a
leak
and
so
it
resets
to
zero
once
you
finalize
you're,
all
of
a
sudden,
it's
zero
again
and
what
happens
here
is
very
likely
if
you've,
if
you've
leaked
back
to
finality
you're
at
two-thirds
you're
at
this
two-thirds
threshold.
B
So
it's
very
easy
to
fall
off
and
fall
into
a
leak
again,
but
the
validators
that
maybe
are
responsible
for
that
leak
at
that
moment,
because
it
forgot
the
magnitude
of
the
prior
leak,
it
kind
of
starts
at
zero,
and
so
it
it
it
can
kind
of
flip-flop
between
finality
non-finality
and
make
very
difficult
to
make
progress.
And
so
this
this
mechanism
also
has
a
memory
and
so
that,
even
though
we
say
we
didn't
finalize
for
200
epochs,
then
we
finalized
for
one.
B
If
we
go
back
into
non-finality
we're
pretty
much
in
a
similar
space
with
respect
to
punitivity
and
can
kind
of
continue
the
leak
from
where
we
were.
Obviously,
if
you
were
finalizing
for
10
epochs
and
you
kind
of
grow
out
of
that
punitivity
domain
and
then
jump
back
in,
but
it
still
has
somewhat
of
a
memory.
B
So
I
didn't
end
up.
Writing
like
the
nitty
gritty
mechanics
of
how
this
works,
but
essentially,
if
I
am,
if,
if
we're
in
a
leak,
so
we're
not
finalizing
and
I
am
not
participating.
My
leak
score
grows
by
four
at
each
epoch.
If
we're
in
a
leak-
and
we
are
fine
and
if
we,
if
we're
in
a
leak
and
I'm
not
participating-
and
I
am
participating,
my
leak
loses
by
one
and
so
essentially
my
leak
score
grows
four
times
faster
than
my
leak.
B
Score
would
degrade,
and
what
we
have
here
is
vitalik
created
this
nice
little
graph.
I
think
it
gives
you
a
nice
intuition
for
what's
happening
before
any
of
these
modifications
you
well
you
have
this
like.
The
leak
is
constantly
growing
the
so
that
the
score
the
the
amount
of
penalty
for
offline
validators
is
constantly
growing,
and
so,
if
you're
offline,
the
entire
time
you
keep
having
this
increased
penalty
and
the
amount
of
your
total
the
amount
that
you've
leaked
entirely
is
the
area
under
this
curve,
and
so
this
nice
triangle.
B
So
the
offline
validator
before
and
after
this
mechanism,
pretty
much
just
loses
a
lot
of
money.
We
can
we'll
go
to
the
leak
resume,
so
you
know
they
lose
this
entire
area
under
the
skirt
this
guy,
like
I
said
this,
call
that
purple
he
was
temporarily
offline
for
this,
like
for
this
nice
stretch
right
here
in
the
event
that
you
have,
you
don't
have
the
per
validator
leak
values.
He
would
have
lost
all
of
this
value.
B
So
the
area
under
this
this
green
stretch
right
here,
but
instead
what
happens
is
his
leak
score
was
zero
until
then.
So
he
really
just
starts
his
personal
leak,
his
personal
journey
into
into
the
fire,
and
he
he
loses
this
amount.
And
then
he
he
comes
back
online.
He's
leaked
store,
starts
degrading
and
he
he
loses
this
amount.
So
much
less.
B
Correct
correct
so
what's
happening
yeah
you
only
leak
when
you're
offline,
so
he
actually
doesn't
leak
during
this
this
amount.
But
if,
at
this
point
he
started
leaking
again,
he
has
there's
the
memory
so
say
he
leaked
from
this
point
until
this
point
there's
the
memory
of
the
leak,
so
his
leak
score
would
start
right
here,
rather
than
starting
back
at
zero
and
so
you're
right.
Thank
you.
B
B
That's
because
he's
greater
than
that
80
threshold,
because
the
leak
he's
online
essentially
like
four
times
longer
than
he's
then
he's
offline
and
so
that
four
to
one
ratio
helps
him
out
and
he
stays
in
a
very
low
league
score
and
has
very
little
leak
and
the
70
validator
who's
slightly
less
than
the
80.
His
league
score
does
grow
over
time
and,
like
vitalik
noted
when
he
is
actually
offline,
he
will
receive
the
area
under
the
curve,
which
is
these
little.
B
Like
slices,
when
the
when
the
yellow
is
going
on
and
the
actual
balances,
the
effect
of
the
actual
balances,
we
see
this
offline,
validator
he's
losing
quite
a
bit.
The
always
online
validator
is
not
losing
anything.
The
90
validator
is
losing
very
little
70
validators,
slowly
he's
lower
than
that
80
threshold,
so
he's
he's
slowly
losing
and
this
temporary
offline
validator,
which
we
saw
highlighted
by
here,
is
kind
of
losing
on
that
accelerated
basis.
B
But
only
during
that
time
that
he
was
offline,
then
his
leaked
score
starts
degrading
and
he
is
online
and
doesn't
receive
an
e
penalty
and
then
what
we're
seeing
here
is
the
memory
of
the
leak
after
finality
has
begun
occurring.
So
before
this
leak
score
mechanism,
this
would
essentially
all
just
drop
to
zero
and
and
everyone
would
all
of
a
sudden
be
wiped
and
nobody
there
would
be
no
memory
of
the
leak.
B
B
He
his
leak
would
begin
right
here
and
begin
climbing
again
from
there,
and
so
what
that
does
is,
even
if
you
have
some
of
these
flip-flop
scenarios,
these
those
offline
validators
that
are
causing
those
flip-flop
scenarios
end
up
having
their
balance,
continue
to
be
penalized
at
a
growing
rate
which
helps
prevent
these
scenarios.
Where
you
end
up
in
a
kind
of
like
these,
these
poor
equilibriums
between
finality
and
non-finality.
B
Let's
see
so,
there
are
a
few
modifications
to
the
consensus
structures
to
get
this
done.
One
is
the
inactivity.
Scores
list
is
added
to
the
beacon
state.
This
is
a
unsigned
integer
per
validator
that
just
keeps
track
of
this
leak.
Score
we've
been
talking
about
all
starts
at
zero
and
grows
from
there.
If
there
is
a
leak,
we
modify
the
penalty
calculations
so
again
at
get
inactivity.
Penalty
deltas
is
based
on
the
inactivity
scores
list.
B
So
it
goes
up
by
four
and
if
we
are
finalizing,
everyone's
league
score
goes
down
by
16.,
so
it
does
just
kind
of
like
the
end
of
epoch,
accounting
to
adjust
everyone's
score
based
off
of
the
state
of
the
chain
and
the
state
of
their
activity,
a
pretty
simple
function,
but
the
kind
of
the
crux
of
this
mechanism,
so
not
too
many
modifications.
The
addition
of
this.
The
addition
of
this
and
a
modification
of
this
function
cool
any
questions.
B
I
know
that
was
a
relatively
complex,
difficult
to
explain
mechanism.
I
do
recommend
the
viewers
to
check
out
the
italics,
annotated
spec.
He
does
a
really
good
job
with
digging
into
this
mechanism
and
digging
into
those
graphs
a
little
bit
more.
But
I'd
love
to
take
some
questions
right
now.
If
you
have
any
cool
and
a
new
duty,
sync
committees,
this
enables
light
clients
as
a
first-class
citizen,
so
validator
duties,
validator
duties
are
really
our
basic
building
blocks
for
mechanism
design.
B
We
have
these
consensus
entities
called
validators
and
we
essentially
tell
them
to
the
protocol-
tells
them
to
do
things
at
various
times
and
for
rewards
and
various
penalties
in
phase
zero.
There's
a
small
number
of
duties,
block
proposal
and
block,
that's
not
a
word,
a
test,
statings
block,
testings
or
block
attestations
and
and
really
that
allows
for
the
core
building
of
the
beacon
chain
and
allows
for
finality
and
other
nice
things
and
to
add
functionality
to
the
beacon
chain.
B
B
So
we
have
some
new
and
modified
duties.
The
first
is
the
sync
committee
signing.
If
I'm
in
a
sync
committee
at
every
slot
that
I'm
assigned
to
sync
committee,
I
check
what
the
head
of
the
beacon
chain
is.
I
sign
a
small
message
that
just
says
the
head
of
the
beacon
chain
is
this:
by
signing
the
beacon
route
and
I
broadcast
that
an
additional
role
to
some
of
those
validators
in
the
sync
committee
is
to
do
sync.
B
Committee,
aggregation
and
so
a
subset
of
this
committee
is
selected
to
aggregate
and
rebroadcast
their
best
aggregate
that
they
can.
They
can
create-
and
this
is
very
similar
to
attestation
aggregation.
It
uses
sub
networks
on
the
p2p
graph
and
it
has
a
few
validators
that
listen
to
messages
of
similar
type
bundle
them
together
with
bls
aggregation
and
send
them
to
a
global
channel,
and
then
sync
aggregate
inclusion.
Each
beacon
proposer
is
allowed
to
include
one
sync
aggregate,
which
is
pretty
much
the
best
aggregate
message
that
signed
the
previous
block.
B
I
there's
a
pr
open
right
now.
I
think
it's
maybe
24-53
that
might
be
slightly
off,
but
it's
a
pr
from
vitalik
potez,
a
contributor
noticed
that
there
were
some
not
so
nice
asymmetries
in
the
way,
validators
rewarded
for
this
duty
and
that
the
duty
was
probably
rewarded
too
much.
And
so
there
are
some
small
modifications
going
to
the
next
alpha
release
of
altair.
B
The
actual
core
of
those
mechanisms
and
the
kind
of
the
ratio
between
these
different
things
and
what
is
rewarded
and
penalized
is
in
very
active
discussion
and
something
is
likely
to
be
merged
today
or
tomorrow.
Based
off
of
that,
so
I
kind
of
left
out
some
of
those
details
here.
Nor
do,
I
think,
they're
very
important
for
the
high
level
understanding
of
this.
B
As
a
so,
there
are
a
few
modifications
to
the
sensor
structures.
There's
the
addition
of
this
sync
aggregate
to
the
beacon
block
body.
So
we
have
beacon
blocks
and
we
have
the
body
of
those
messages
and
there's
the
sync
aggregate
that
goes
in
there
and
it's
really
just
a
bit
field.
So
it's
who
participated!
This
is
very
similar
to
attestations
who
participated
and
then
it's
a
bls
signature,
which
is
just
a
bunch
of
bytes
that
can
be
verified
that
those
people
actually
participated
and
signed.
B
That
message,
there's
the
addition
of
the
sync
committee
into
the
beacon
state.
So
the
next
and
current
sync
committee
is
added
to
the
beacon
state.
This
is
to
simplify
like
clients
in
a
sense
I
think
vitalik
will
probably
get
into
this,
but
it
essentially
allows
for
caching
and
being
able
to
serve
some
of
the
pub
key
data
to
validators.
They
don't
have
to
do
intensive
calculations
against
the
entire
validater
set
process.
We
process
sync
committee,
so
add
processing
committee
to
the
function
process
block.
B
So
every
time
a
block
comes
in
there's
this
addiction
additional
function
that
runs
and
it's
pretty
much
validating
this
sync
aggregate.
Payload,
so
it's
saying,
okay,
who
participated
is
the
signature
actually
valid
is.
Does
this
actually
point
to
the
previous
beacon
block
and
then
issue
those
small
rewards
to
the
participants
and
the
proposer
and
then
update
sync
committee?
This
is
added
to
process
epoch
and
this
actually
happens
every
time.
The
sync
committee
period
changes
and
that's
every
which
is
actually
changing.
B
Today,
every
256
epochs
was
about
about
every
day
the
sync
committee
changes
and
what
happens?
Is
the
next
committee
data
structure
gets
put
into
the
current
committee
data
structure
because
it's
now
the
current
and
the
next
committee
for
the
next
epoch
next
period,
sync
committee
period
is
calculated
and
embedded
and
that's
that's
kind
of
the
core.
The
consensus
changes
here.
It's
really
fairly
simple
on
the
consensus
changes.
B
It's
really
the
the
the
core
of
it
is
reusing,
some
of
the
similar
attestation
structures
and
duties
on
the
p2p
layer
and
kind
of
making
sure
that
the
validator
client,
the
complexity,
really
lies
in
the
validator
client
like
requesting
duties,
making
sure
they're
signing
things
and
broadcasting
things
and
aggregating.
But
most
of
it
really
is
reutilizing
structures
that
have
been
very
refined
for
the
attestation
duties,
because
it
looks
very
similar
to
the
abstraction
duty.
B
Okay,
that's
the
core
of
the
consensus
changes
related
to
those
things
just
through
this
out
here.
The
annotated
spec
is
a
really
really
great
resource
that
vitalik's
been
working
on.
Here's
a
link
to
that
the
eth
r
d
discord
we're
always
hanging
out
talking
about
all
these
things.
I'm
on
twitter
and
now
vitalik
is
going
to
talk
to
us
about
like
client
sync
protocol.
C
I'm
happy
to
move
I'll
put
my
slides
up
excellent
okay,
so
the
light
client
sync
protocol.
Okay,
there
we
go
full
screen
it,
okay,
so
basically,
so
this
is
the
pro
the
mechanism
by
which
we,
like
light
clients,
are
going
to
stick.
So
just
you
know
have
the
full
diagram
here
and
I'll
go
through
the
diagram
piece
by
piece:
it's
actually
much
less
much
less
intimidating
than
it
seems,
so
I
guess
to
kind
of
start
off
from
a
high
level.
C
They
don't
have
a
large
amount
of
storage
and
you
cannot
even
reasonably
expect
them
to
have
more
than
like
a
very
tiny
amount
of
bandwidth
right
so,
like
expected
use.
Cases
of
this
would
include
wallets
inside
of
mobile
phones,
which
currently
pretty
much
I'll
just
talk
to
in
fura
or
talk
to
you
know
like
some
like
a
local
alternative
to
interior.
C
They
include
in
browser
wallets,
like
metamask
and
potentially
the
even
the
most
radical
thing
that
this
includes
is
well
light
clients
that
are
smart
contracts
inside
of
other
blockchains.
So
this
is
if
he
wants
to
make
bridges
to
ethereum
from
other
systems.
So
the
goal
is
just
like
very
tight
resource
constraints
right
and
we'll
talk
about
what
how
much
resources
the
select
line
protocol
actually
requires.
C
So,
first
we'll
start
off
by
talking
about
how
the
the
white
client
keeps
track
of
finalized
blocks
and
then
at
the
end
it
also
gets
to
kind
of
some
ideas
for
how
this
could
be
extended,
and
you
can
so.
The
like
clients
can
have
a
kind
of
faster
response
time
and
also
get
blocks
that
have
not
been
finalized
right.
So
the
the
way
that
define
the
protocol
is
kind
of
inductively
right.
So
we
assume
the
client
knows
some
block
header,
and
this
is
just
a
block
header.
C
C
There
is
a
state
route
and
inside
of
the
state,
you
have
the
current
sync
committee
and
the
next
committee.
So
these
thing
committees
are
sets
of
512
validators
and
importantly,
this
object
inside
the
state.
It
doesn't
just
store
the
indices,
it
directly
stores
their
public
keys
right.
So
if
you
just
verify
this
one
merkle
branch,
then
you
can
grab
either
the
currency
committee
or
the
next
sitting
committee
or
or
just
both,
and
you
will
be
able
to
like
just
download
this.
C
So
each
of
these
committees
has
512
validators
of
48
bytes,
each
so
512
times,
48,
that's
24,
576
bytes,
so
24k,
plus
a
little
more
for
the
marco
branch,
plus
a
little
more
for
the
header.
And
then
when
you
have
the
sig
committee,
you
basically
have
the
public
keys
that
you
will
be
able
to
verify
these
sync
signatures
against
right.
C
So,
as
danny
mentioned,
where
there's
this
mechanism,
where
the
sync
committee
members
are
supposed
to
publish
signatures
every
slot
of
the
next
or
of
the
what
they
consider
to
be
the
most
recent
block
header
or
the
most
recent
block-
header,
that's
of
at
the
head
of
the
chain-
and
so
they
make
signatures
and
the
block
proposer
aggregates
them.
But
like
really
anyone
on
the
network
can
aggregate
them.
You
can
make
an
aggregate
signature
and
an
aggregate
signature
would
also
come
with
a
participation
bid
field.
C
That
just
says
like
out
of
these
particular
participants
who
actually
participated.
So
if
you
have
the
participation
bit
field,
then
you
can
extract
the
subset
of
the
sync
committee
that
participated
and
then
you
just
do
like
a
standard
signature
verification
algorithm.
So
this
is
an
aggregate
signature
of
this
header
and
if-
and
so
you
verify,
the
signature
against
the
set
of
public
keys
that
actually
participated
and
then
the
message
that's
being
signed
just
is
the
the
root
of
the
block
header.
C
C
Now,
if
you
want
to
get
a
block
header
that
is
actually
known
to
be
finalized,
then,
or
at
least
like
that
is
known
to
be
finalized
conditional
on
this
assumption
that
at
least
two-thirds
of
the
same
committee
is
honest,
then
you
basically,
you
would
grab
a
merkle
branch
from
this
header
right
from
the
and
then
that
merkel
into
that
merkle
branch,
you
would
walk
in
and
you
would
grab
the
finalized
checkpoint
right.
The
finalized
checkpoint
is
basically
the
most
recent
finalized
block.
C
That's
that's
saved
in
the
state
and
then
from
that
final
finalized
checkpoint
that,
like
that,
includes
a
block
header
hash,
and
so
you
would
be
able
to
grab
a
block
header.
That's
like
two
ebox
older
than
this
block
header,
but
that
actually
is
like
guaranteed
to
be
to
be
finalized
and
so
like
that
can't
be
reverted
right
so,
like
just
for
simplicity
purposes,
this
particular
kind
of
like
light
mechanism.
C
It's
tracking
finalized
blocks.
Just
so
that,
like
this,
this
mechanic
doesn't
have
to
contain
any
kind
of
fortress
rule.
It
does
not
contain
any
kind
of
possibility
of
reverting
right,
so
it
just
like
so
so
far
this
this
is
going
to
lag
kind
of
two
epochs
behind
the
head
of
the
chin.
But
you
know
it's
not
going
to
revert
unless
there's
some
really
terrible
attack.
A
C
If
there's
a
really
terrible
attack,
then
you
probably
want
to
like
go
in
and
revert
manually.
So
this
is
a
lot
of
information.
Just
recapping
you
have
the
header
step,
one.
You
grab
the
sync
committee
by
merkel,
verifying
it
against
the
header
step.
Two.
You
grab
the
signature
of
the
future
header
and
you
verify
the
sync
committee
or
you
verify
the
signature
against
the
same
committee
and
against
the
header.
So
now
you've
verified
this
header
and
then
step
three
from
this
header.
C
You
kind
of
walk
back
a
bit
and
you
get
the
finalized
header.
Okay,
perfect,
so
just
going
through
a
couple
of
nuances.
So,
first
of
all,
like
one
one
nuances
like,
why
do
you
commit
to
both
the
currency
committee
and
the
next
committee,
and
so
sick
committee
periods
are
256
epochs
long
and
basically
the
reason
you
need
both
is
because
this
newer
block
is
could
be
in
the
same
period
or
it
could
be
in
the
next
period,
and
so
you
have
to
cover
both
cases.
C
C
So
I
think
the
way
that
this
that
it's
being
designed,
or
at
least
specked
in
altair
right
now,
is
that
we
have
this
object.
Called
a
white
client
update
and
a
like
line.
Update
just
contains
everything
right.
So
the
like
line
update
contains
the
sake
committee.
It
contains
the
branch
it
contains,
the
aggregate
signature
it
contains
the
midfield
it
contains
the
this
header.
It
contains
the
vertical
branch
from
this
header
to
the
finalized
header.
C
It
contains
the
finalized
header,
so
it
just
like
grabs
all
the
information
that
you
need
to
verify,
and
it
it
just
like
puts
it
into
one
single
package
and
then
the
white
clients
can
just
perform
all
of
the
verification
steps
on
that
one
package
right
so
like
there
isn't
any
kind
of
multi-round
network
access
protocol.
It's
just
the
lifeline
asks
for
a
thing,
but
whether
the
lifeline
gets
the
thing.
B
C
A
C
Also
so
another
note
of
the
the
white
client
servers
do
not
have
to
be
trusted,
though
the
light
clients
should
connect
to
multiple
phone
notes
to
ensure
aliveness
through
redundancy,
and
so,
if
one
of
them
like
tries
to
block
out
certain
information,
the
other,
then
the
client
can
still
get
it
from
the
other
servers.
Basically,
so
you
can
either
get
the
like
client
signatures
from
the
block
header
right.
C
So
the
eli
client
signatures
are
required
to
be
included
in
the
block
header
if
he
wants
to
get
the
reward
for
them,
but
also
nodes
could
just
get
the
signatures
directly
from
the
peer-to-peer
network
if
they
want
to
like
get
the
information
faster
or
they
yeah
wants
to
use
the
peer-to-peer
network.
But
what
the
other
thing
they
could
do
is
they
could
grab
signatures
from
the
block
header
and
then,
if
they
also
see
other
signatures
in
the
peer-to-peer
network,
that,
like
add,
even
add-on
even
more,
they
should
just
add
them
all
themselves.
C
Right
so
this
is
kind
of
like
this
part
is
fairly
free-form
for
the
white
client
server.
It
can
be
implemented
in
any
of
different
ways,
but
the
litecoin
server
should
just
be
striving
to.
You
know,
balance
between
providing
all
of
the
signatures
that
they
can
find
and
providing
them
in
a
timely
manner.
C
They
can,
but
they
don't
have
to
right
so
so
far.
This
is
designed
in
such
a
way
that
a
client
does
not
have
to
have
any
kind
of
your
code.
The
litecoin
just
has
to
have
like
a
list
of
ip
addresses
of
servers,
but
if
desired,
like
you
could
do,
you
could
have
a
subnet
for
like
client
updates.
That's.
C
B
C
That
definitely
was
a
problem,
and
so
piper's
team
is
like
now
working
on
the
portal
network
right,
which
is
basically
a
yet
different
approach
to
that.
That
makes
it
more
easy
for
nodes
to
have
part
of
the
state
and
serve
each
other.
One
import,
really
important
kind
of
note
to
on
that
whole
topic
is
that
light
clients
need
full
notes
or
the
rest
of
the
network
for
two
different
tasks.
One
of
them
is
learning
what
the
correct
block
headers
are,
and
the
second
is
given
correct.
C
Block
headers
get
vertical
branches
for
all
the
state
that
they
wants
to
access,
and
this
whole
protocol
so
far
is
handling
only
the
first
right,
so
for
the
second
like
yeah
yeah
and
a
different
protocols
would
be
required,
and
this
the
first
is
not
very
intensive
right.
The
first
is
like
only
a
couple
of
kilobytes
it's
of
one
data,
but
the
second
so
actually
getting
the
mortgago
branches
like
that's
something
that
could
be
more
intensive,
and
so
I
can
see
like
so
far.
C
B
C
Okay,
so
finalized
versus
non-finalized
updates,
so
like
there's,
two
types
of
like
line,
update
and
really
the
word
type
should
be
in
quotation.
Mark
because,
like
technically,
it's
one
struct,
but
basically
like
there's
two
sort
of
ways
to
put
data
into
that
struct
in
such
a
way
that
a
light
client
running
the
the
spec,
the
specified
protocol
would
consider
it
valid
and
I
call
them
finalizing,
updates
and
non-finalizing
updates.
C
So
a
finalizing
update
contains
these
two
headers,
so
it
contains
the
sign
header
and
it
contains
to
find
the
header
that
is
to
finalize
checkpoints
in
the
state
of
a
signed
header
and
it
recontains
a
merkle
proof
proving
that
second
header
and
a
like
a
light.
Client
accepts
the
the
the
finalized
header
as
being
a
kind
of
its
new
route,
and
this
for
a
finalizing
update
to
be
valid.
The
signature
must
have
at
least
two-thirds
participation.
C
So
blocks
that
are
less
than
two
e-box
old
are
have
to
be
handled
differently
because
it's
important
to
learn
them,
but
there
is
at
least
theoretically
the
possibility
that
they
get
reverted,
and
so
the
white
clients
will
not
accept
that,
like
a
a
block
that
recent
that's
a
stupid
right,
because
it's
not
finalized
so
like
client
store
the
way
it's
currently
specified
like
points
store,
the
best
known
finalized
header.
So
there's
a
like
a
field
in
the
like
client
store.
C
I
think
it's
just
called
header
and
that's
the
header
that
they
kind
of
currently
accept
as
being
the
one
that
they
know
about,
and
they
also
store
a
set
of
non-finalized
non-finalizing
updates
and
if
a
client
sees
no
like,
does
not
update
its
finalized
header
for
a
day,
then
they
accept
the
non-finalized
update
that
has
the
highest
score.
So
when
I
say
score,
it
just
means
like
the
percent
of
the
sync
committee
that
signed
it.
They
accept
the
the
the
non-fi
the
highest
scoring
non-finalizing
update
as
finalized
right.
C
So
if
the
like
client
kind
of
keeps
trying
and
keeps
looking
for
a
new
finalized
header
for
an
entire
day,
but
it
just
keeps
on
getting
non-finalized
updates
that
have
less
than
two-thirds.
Then
then
that
probably
means
that
you're
in
an
inactivity
leak
and
then,
after
the
day,
the
light
glance
just
grabs
the
header
with
the
with
the
highest
score
and
the,
and
that
just
allows
the
like
blindness
to
keep
to
keep
progressing
even
during
an
inactivity
leak.
C
So
another
kind
of
optional
feature
thing.
This
is
not
part
of
the
spec
currently,
but
this
is
something
that
my
clients
are
totally
able
to
do
under
like
this
is
just
purely
a
client-side
calculation,
which
is
if
a
light
client
wants
to
get
information
about
a
very
recent
block
which
no,
he
wants
to
do
right
like
if
people
want
to
learn
about
things
that
happened
recently,
basically
or
under
conditions
of
non-finalization.
C
My
clients
can
use
their
store
of
non-finalized
updates
to
try
to
compute
the
head
right.
So
the
way
that
this
so
there's
like
different
possibilities
for
how
to
design
for
how
to
design
this
algorithm,
but
like
one
simple
one,
is
to
kind
of
what
I
call
the
recursive
highest
scoring
descendants
rule.
So,
basically,
like
you
could
look
at,
you
could
look
for
blocks
that
have
the
highest
that
have
the
highest
score,
so
meaning
the
highest
percentage
of
the
same
committee
participating
in
them.
C
C
You
would
accept
this
block
as
being
the
head
because
well,
this
block
over
here
has
25
percent
and
the
block
has
ten
percent,
and
so
it's
clearly
kind
of
the
better
child
of
the
one
that
has
sixty
percent
right
so
like
these
are
things
that,
like
clients,
can
do
a
kind
of
client
side
to
try
to
figure
out
what?
What
the
very
most
recent
vlog
is.
C
Basically,
if
you
want
to
get
block
headers
that
are
more
recent
than
two
e-books
and
then
like
you
could
kind
of
look
and
sort
through
the
information
that
you
have
in
your
non-finalized
updates.
You
could
even
ask
client,
certainly
client
servers
to
give
you
more
non-finalized
updates
and
that's
the
way
that
you
can
get
the
most
recent
blocks.
E
C
C
Sorry
that
when
I
get
like
when
I
talk
about
like
weights
or
scores,
I
just
be
in
the
percent
of
the
sync
committee
that
participated
in
a
signature
of
that
particular
header
so
like
this
is
just
an
example
right
like
if
you
have
this
sort
of
situation
where
you
get
these
blocks
and
then
like
this
one
has
a
10.
This
one
has
10
and
like
if
you
just
look
at
these
two
then
like
it
looks
like
15,
is
more
than
10,
but
then
over
here,
like
really
have
a
descendant.
That
has
more.
C
B
Little
bit
tangential,
you
mentioned
it
very
briefly
that
there's
discussion
about
using
light
clients
and
actually
embedding
them
on
smart
contracts.
You
mentioned
potentially
using
them
smart
contracts
on
other
chains.
Would
they
also
be
able
to
be
embedded
inside
the
chain
to
give
a
smart
contract
awareness.
C
Of
of
the
block
state
like
what
block
it
is
or
how
many
blocks
have
passed,
so
you
mean
like
if
for,
for
example,
like
you,
would
have
smart
contract,
like
I
don't
know,
tesla's
included
asian
life,
clients
of
the
youth
2
chain,
then
like
what
a
smart
contract
and
like
tesla's
be
able
to
see
like
state
of
the
e3
chain.
I.
B
I
meant
more
around
automation
like
that.
The
the
smart
contract
might
be
able
to
be
aware
right
now,
generally,
while
you
can
conditionally
put
something
in
a
smart
contract
for
it
to
be
able
to
be
executed
after
a
certain
amount
of
time,
the
contract
itself
would
not
be
able
to
execute
would
apply.
C
A
C
And
then
you
would
also
need
outside
actors
to
pass
in
merkel
branches
like
if
you
want
to
actually
then
use
the
headers
to
learn
things
uh-huh,
okay,
yeah.
I
also
promised
metrics
and
like
well.
I
think
I
gave
the
most
important
metric,
which
is
like
per
day
it's
basically
about
25
kilo
or
25
kilobytes
for
an
update
that
includes
the
new
committee,
so
we're
basically
talking
about
25.
C
D
B
B
I
think
really
we're
targeting
an
august
altair
launch
at
this
point
just
given
the
amount
of
spec
changes
that
happened
over
the
past,
probably
five
weeks
and
just
the
work
that
was
going
on
with
reianism.
That
was
definitely
a
lot
of
teams
priorities
for
about
a
month
and
a
half
so
we're
just
certainly
a
little
bit
behind
than
what
we
expected,
but
aiming
for
a
late
summer.
Release.
D
B
Crater,
so
I
think
piermont
is
the
older
of
those
paramount
will
be
forked
and
then
likely.
The
support
for
paramount
will
be
deprecated.
I
think
we
were
waiting
on.
We
wanted
to
utilize
it
for
this,
and
rocketpool
was
finishing
up.
Beta
marketpool
is
done
with
that
beta,
and
so
the
last
thing
on
its
lifetime
officially
will
be
this
fork.
A
B
Yes,
they're
almost
finalized.
If
this
is
a
week
ago,
we
can
have
a
go,
I
would
have
said
they
were
but
like,
like
we've
been
talking
about,
we
discussed
a
breaking
change
with
respect
to
sync
committee
rewards
on
the
call
this
morning
and
pretty
much
got
the
thumbs
up
on
a
pr
that
has
been
reviewed
and
tested
and
will
be
integrated
into
alpha
7
release.
I
do
not
expect
any
more
changes
with
respect
to
those
unless
some
serious
issue
has
is
identified,
which
I
don't
expect,
but
it
always
could
happen.
A
All
right,
that's
really
nice
to
know
so
the
duties
rewards
and
penalties.
They
seem
to
be
intertwined.
So
in
your
experience,
which
have
helped
in
validators
being
more
committed,
may
be
motivated
towards
performing
their
duties,
increasing
reward,
increasing
penalties,
losing
reward
and
no
penalty,
or
is
there
any
other
mix?
That
team
is
considering.
B
B
A
C
The
idea
is
of
a
discouragement
attack
is
basically
like
to
use
a
grieving
attack,
so
an
attack
that
causes
another
validator
to
either
lose
rewards
or
suffer
a
penalty
with
the
goal
of
like
basically
increasing
the
chance
that
that
validator
drops
out
and
therefore
reducing
the
amount
of
participation
and
so
like.
You
would
get
higher
a
higher
interest
interest
and
like
a
higher
participation,
a
share
of
proposed
rewards
in
the
future.
So
like
it's,
I
I
use
a
yeah
in
an
important
use
case
of
griefing.
C
So
for
this
again,
and
it's
a
big
reason
why
we're
very
careful
about
like
opening
up
pathways
by
which
validators
and
like
yeah
and
even
large,
that's
large
sets
of
elevators
could
do
things
that
cause
other
validators
to
lose
money
and
reach
right
like
when
those
are
inevitable.
We
try
to
make
them
as
expensive
as
possible.
A
In
terms
of
resources,
I
know
it
was
also
mentioned
in
one
of
the
slides
that
the
discard
channel
is
there
the
annotated
specs
are
there?
I
just
wanted
to
confirm,
like
I
also
came
across
this
hf1
document.
Is
that
still
valid,
or
is
there
any
other
document
that
people
can
refer
to
if
they
want
to
educate
himself
about
the
consensus
they
are
upgraded.
B
Hf1
document
was
kind
of
a
working
document
before
we
hit
the
specs,
and
so
some
of
the
high
level
intention
discussed
there,
I
think,
is
still
valid,
but
I
think
most
of
it
now
is
covered
in
the
specs
and
in
vitalik's
annotated,
spec.
I
think
those
are
probably
the
best
the
best
resources
at
this
point
and
definitely
come
merge
the
process
and
formality
on
how
these
things
are
upgraded
and
where
all
the
information
is
stands,
especially
with
respect
to
eips,
and
things
like
that
is
certainly
will
evolve.
A
A
This
consensus
layer
upgrade
episode.
We
are
trying
to
bring
it
in
parts
for
community
to
learn
every
features
that
are
getting
into
the
upgrade
feel
free
to
drop
and
comment.
If
you
have
any
questions
that
couldn't
be
answered
in
this
episode
or
the
former
episode
that
we
did
with
alex
you,
you
can
always
contact
us
as
usual.
We
love
to
hear
feedback
and
improvement
suggestions
for
this
series.
A
You
can
directly
reach
ethereum
catalogues
and
discord
and
twitter
handles
of
the
guests
are
provided
in
the
description
you
may
reach
directly
to
them.
For
for
your
questions
next
week
we
will
be
joined
by
alex
pavel
and
andrei
to
talk
about
eip3541
that
is
expected
with
london
upgrade
so
stay
tuned.
Keep
watching
keep
sharing
your
love
with
the
idiom
cat
holders.
This
is
all
of
us
signing.