►
Description
Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on Swarm, IPFS and more.
https://archive.devcon.org/archive/watch/6/reducing-beacon-chain-bandwidth-for-institutional-and-home-stakers/
This talk gives an overview of the networking infrastructure of beacon nodes and details some of the recent research being done significantly reduce the growing bandwidth requirements of the Ethereum consensus layer.
In particular, we will discuss the network requirements of gossipsub, how long-lived subnets can be the cause and a potential solution to high bandwidth usage as well as preliminary results from experiments with an experimental extension to the gossipsub protocol, episub.
Speaker(s): Adrian Manning, Diva
Skill level: Intermediate
Track: Layer 1 Protocol
Keywords: consensus,networking,staking
Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum
Learn more about devcon: https://www.devcon.org/
Learn more about ethereum: https://ethereum.org/
Devcon is the Ethereum conference for developers, researchers, thinkers, and makers.
Devcon 6 was held in Bogotá, Colombia on Oct 11 - 14, 2022.
Devcon is organized and presented by the Ethereum Foundation, with the support of our sponsors. To find out more, please visit https://ethereum.foundation/
A
A
B
So
first
thing
that
we
need
to
check
in
order
to
analyze
how
to
reduce
bandwidth
for
institutional
and
homesteakers
is
how
does
the?
What
does
the
bandwidth
look
like
right
now
we
are
going
to
be
looking
at
data
from
Lighthouse
like
age
said.
We
work
on.
Lighthouse
is
one
of
the
production
Beacon
notes.
There
are
many
others
techu
prism,
Nimbus
low
star.
We
are
the
second
most
popular
one,
and
while
the
data
we're
going
to
be
looking
at
is
lighthouse,
we
are
certain
that
this
applies
to
any
other
client
across
the
network.
B
You
can
see
that
it
increases
when
the
number
of
validators
goes
up,
but
then
at
64
validators
it
stays
more
or
less.
The
same.
64
is
going
to
be
a
really
important
number
in
this
talk.
H
is
going
to
explain
further.
Why
and
why
it's
important
so
yeah.
We
need
to
remember
simply
that
we
are
going
to
stop
at
64,
and
this
is
where
bandwidth
is
going
to
be
more
or
less
stable.
B
Now,
if
we
look
at
how
many
validators
does
every
Beacon
node
on
the
network
has
we're
going
to
have
like
main
three
groups,
we're
going
to
have
those
that
don't
have
any
validator
attached?
Only
simple
Beacon
notes,
notice,
taking
big
notes
now
we're
going
to
have
those
that
we
are
going
to
come
homesteakers
which
have
less
than
10
validators
in
this
graph
you're
going
to
see
a
very
big
bar.
That's
the
one
with
see
your
evaluators
I
hope
you
can
see
it.
B
Those
are
a
very
big
chunk
of
the
network,
almost
60
percent
of
the
network.
Then
we
have
those
that
we
call
homesteakers.
Most
of
them
have
just
one
validator,
and
then
we
have
those
that
we
call
institutional
stakers.
Those
are
the
ones
that
have
more
than
64
validators,
which
is
the
big
board
at
the
end.
Now,
why
do
we
care
about
bandwidth
to
begin
with,
so
there
are
a
couple
of
downsides
of
high
bandwidth.
The
first
one
is,
of
course,
an
increased
cost.
B
So
we
need
to
start
tackling
this
problem
right
now
before
this
happens.
That's
another
big
reason
why
this
is
important.
Also.
Another
really
really
important
reason
is,
when
we
say,
for
example,
A
diversity
problem.
The
truth
is,
if
you
are,
for
example,
a
homesteaker
and
you're
running
your
beacon
note
with
your
single
body
data
attached
and
then
your
brother
or
your
sister
starts
playing
video
games,
then
you're
going
to
have
a
bandwidth
Spike
and
you
might
lose
at
the
stations
you
might
miss.
B
Other
stations
blocks
so
basically
you're
losing
money
simply
because
very
very
short,
the
spikes
in
bandwidth
so
yeah.
We
don't
want
that
now,
let's
check:
where
is
the
bandwidth
coming
from?
For
the
sake
of
this
talk,
we
are
going
to
separate
protocols
between
discovery
and
non-discovery.
So
why
is
that?
Because
Discovery
has
its
own
transport,
its
own
encryption,
it's
over
UDP,
whereas
all
the
leave
P2P
we're
going
to
call
them
lip.
B
P2P
protocols
they're
over
TCP
we
have
gossips
of
and
the
request
response,
the
one
we
are
going
to
be,
focusing
mainly
in
the
stock
is
Gossip.
So
now
that
we
have
this
separation
between,
let's
say
Discovery
and
not
Discovery,
let's
check
where
is
the
bandwidth
coming
from?
This
is
what
the
bandwidth
total
bandwidth
looks
like
for
one
of
our
nodes
for
the
last
couple
of
days.
Is
it
Discovery?
Is
it
live
PDP?
B
Where
is
it
so
now
we
have
two
graphs:
the
purple
one
is
going
to
be
Discovery
as
all
the
discovery
bandwidth
and
the
other
one
in
the
bottom
is
dollar
v2p.
Bandwidth
now
forget
about
the
scales.
This
is
just
like
a
non
node,
very
sciency.
Analysis
of
the
shape
of
the
shape
of
the
bandwidth
so
I
guess
we
can
more
or
less
agree
that
bandwidth
has
the
shape
of
the
leaf
P2P
when,
whereas
Discovery
is
well,
it's
very
magical,
as
we
will
see,
so
the
total
bandwidth
is
around
250
kilobytes
per
second.
B
Is
it
better
like
this
yeah,
okay,
about
250
kilobytes
per
sec
per
second,
then
we
have
lip
PDP,
which
is
around
200
kilobytes
and
then
discovery
which
is
between
40
and
60
kilobytes
per
second.
So
for
the
sake
of
doing
analysis,
over
pan
with
Discovery
is
really
not
important,
so
we're
going
to
focus
only
with
P2P,
so
I
was
saying
we
have
gossips
up
and
request
response,
we're
going
to
focus
on
Gossip
stuff,
so
in
Gossip,
so
gossip
soap
is
a
published,
subscribe
system
protocol.
B
B
We
have
large
amounts
of
data
and
those
will
split
between
subnets
again.
Here
we
have
64
attestation
subnets,
which
again
age
is
going
to
be
talking
further
in
a
moment,
and
then
we
need
to
think
how
many
subnets
are
we
subscribed
to,
since
this
is
since
this
is
the
reason
why
we
get
so
many
so
much
bandwidth,
and
the
reason
is
that
right
now
is
because
now
they're
subscribing
to
one
subnet
for
each
validator
that
it
has
attached
and
yeah
well,
subscribing
to
a
subnet
means
a
lot
more
of
bandwidth.
B
So
a
very
simple
example
of
how
gossip
stuff
works.
Gossip
stuff
has
a
lot
of
parameters,
but
one
that
we
care
a
lot
is
the
match
degree.
So
this
example
is
the
three
three
match
degree.
So
we
are
going
to
start
with
our
guy
in
the
middle
that
one
I
hope
you
are
seeing
the
red
circle
just
right
in
the
middle,
so
this
guy
has
a
validator
attached.
B
It's
going
to
publish
a
block,
so
it's
going
to
beg
to
pick
three
Piers,
it's
going
to
disseminate
the
message
and
then
each
period
is
going
to
do
the
same
with
some
other
three
peers
and
so
on
and
so
on.
So
if
you
think
about
this
for
a
moment,
you're
going
to
realize
that
is
very
likely
that
I
know
this
is
going
to
receive
one
single
one,
unique
message,
a
lot
of
times
from
very
different
notes
across
very
different
paths
in
the
network
from
the
source
to
themselves
Okay.
B
So
why
do
we
like
gossip
stuff,
or
why
do
we
like
the
way?
We
do
this,
this
message
propagation?
So
it
makes
for
a
very
robust
Network
in
the
sense
that
we
are
sure
that
if
we
publish
a
message-
and
we
have
this
kind
of
topology-
the
message
is
going
to
reach
all
other
nodes
in
the
network
in
a
timely
manner.
We
also
know
that
we
have
low
message.
Latency
does
mean.
B
This
is
a
graph
that
we
have
for
nodes,
so
this
is
like
real
data
for
the
gossips
of
duplicates.
Now
this
is
going
to
be
weird
but
I'm,
going
to
ask
you
to
focus
on
this
number,
the
beacon
block,
so
we
know
we
need
to
publish
one
block
each
slot.
So
we
know
for
this
topic.
We
are
supposed
to
receive
a
single,
unique
message.
However,
we
are
getting
six
or
seven
messages
across
the
network.
That
means
an
application,
an
amplification
factor
of
about
seven.
B
So
imagine
what
happens
if
we
were
able
to
reduce
that
kind
of
duplicates.
That
was
like
a
huge,
huge
gain
there.
Okay,
so
a
summary
of
the
current
state,
so
bandwidth
is
proportional
to
the
number
of
validators
I
know
it
has.
H
is
going
to
speak
about
how
we
intend
to
tackle
this,
and
the
other
one
is
the
high
amplification
in
Gossip.
So
how
are
you
going
to
do
to
reduce
duplicates
without
harming
the
network,
so
I'm
going
to
leave
Ash
to
continue
this
talk,
foreign.
A
Yeah
thanks
Diva,
so
I'm
gonna
try
and
have
a
crack
at
explaining
how
we
can
potentially
reduce
some
of
these,
so
I'm,
Australian
and
I
can
see
a
few
Australians
in
the
audience.
I
think
they'll
agree
with
me
that
we
have
terrible
internet
like
ridiculous
internet
I
run
a
validator
at
home
and
someone
that
watches
Netflix
in
another
room
causes
me
to
lose
attestations
so
I
as
a
disclaimer
I
have
a
personal
Vendetta
to
try
and
actually
reduce
this
bandwidth
so
that
I
stop
losing
out
of
stations
yeah.
A
So
there's
probably
two
solutions.
We
have
to
these
kinds
of
problems
which
I
just
want
to
kind
of
briefly
touch
on
and
give
you
a
feel
for
what
we're
trying
to
work
on.
One
of
them
is
called
minimizing
topic
subscriptions.
Let
me
try
and
explain
that
if
you
haven't
already
covered
some
of
this
kind
of
stuff
before
so
a
validator
in
an
Epoch
needs
to
do
some
kind
needs
to
publish
the
messages
on
these
things
called
subnets.
A
In
order
to
do
that,
you
need
to
have
peers
to
be
able
to
publish
those
messages
on
those
subnets
now.
The
problem
with
this
is
that
peer
Discovery
is
kind
of
is
a
slow
process.
It
takes
a
while
to
actually
find
some
peers
and
it's
even
harder
to
find
a
peer
on
a
specific
subnet
that
you
need
to
publish
an
attestation.
A
So
the
problem
we've
got
essentially
is
that
we
need
a
stable
set
of
subnet,
a
stable
set
of
pairs
that
exist
on
each
subnet
that
we
can
find
them
easily
when
we
need
to
publish
a
message.
So
it's
not
really
an
an
easy
problem
to
solve
the
the
way
that
we
currently
have
this
solution.
I
guess
is
that
every
time
a
validator
is
attached
or
sends
a
message
to
your
beacon
node.
That
Baker
note
is
required
to
subscribe
to
one
subnet
for
a
very
long
period
of
time
it's
about
27
hours
or
256
epochs.
A
So
what
that
means
is
the
more
validated
you
have
attached
to
your
Beaker
node,
the
more
subnets
you
need
to
subscribe
to
and
subscribing
to
a
subnet
means
that
you
have
to
get
all
of
the
messages
on
that
subnet.
You
need
to
verify
those
messages
and
then
you
need
to
send
them
on
to
other
peers.
So
you're
doing
this,
there's
a
lot
of
bandwidth
and
a
lot
of
processing
so
essentially
you're
supporting
the
network
at
the
cost
of
bandwidth
on
your
node,
so
you're
kind
of
being
like
a
good
actor.
A
So
there's
a
number
of
downsides
to
this
approach.
One
is
that
it's
not
enforceable.
So
what
that
means
is
you
as
a
beacon
node?
You
can
essentially
lie
to
us
and
you
say:
I
don't
have
any
validators,
even
though
you've
got
like
2
000
attached
to
you
and
you
just
don't
subscribe
to
any
long-lived
subnet.
So
you
don't
consume
any
bandwidth.
So
you
kind
of
incentivized
to
do
this
and
there's
no
way
that
any
other
node
on
the
network
can
tell
whether
you're
lying
to
us
or
not.
A
The
next
thing
is
potentially
our
subnets
are
oversubscribed.
We
actually
have
quite
an
a
large
number
of
Beaker
nodes
on
mainnet
today
and
when
we
originally
designed
this
kind
of
process,
we
we
didn't
really
realize
how
many
nodes
would
be
participating
in
the
network.
So,
potentially
we
have
more
nodes
than
we
need
on
each
of
these
subnets,
so
that
would
lead
us
to
think
that
we
have
excess
bandwidth
on
the
network
that
potentially
we
can
remove.
A
So
the
idea
that's
being
proposed
is
why
don't
just
every
single
Beaker
node
on
the
network
subscribe
to
one
or
many
subnets?
The
there's
some
benefits
to
this,
but
the
journal
discussion
is
in
is
in
this
specs
repo
as
an
issue.
So
what
would
the
bandwidth
graph
look
like
if
we
did
this,
if
one
Beaker
node
were
subscribed
to
one
subnet
rather
than
having
it
for
being
proportional
to
the
number
of
validators
attached
to
you?
A
You
would
then
get
this
green
line
on
this
graph,
which
hopefully
everyone
can
see,
and
that
green
line
sits
at
around
500
kilobytes,
a
second
at
the
moment,
from
what
we've,
what
we've
measured.
So
essentially
everybody
on
the
network
that
has
a
validator
wins
in
this
in
this
scenario,
except
for
those
that
have
one
so
sorry
for
the
people
that
only
have
one
validator
in
this
room,
you
guys
then
have
to
your
bandwidth
will
increase
by
about
500
to
100
kilobytes.
A
The
other
benefit
that
we
get
from
this,
so
from
a
quick
scan
that
we
did
of
the
of
the
DHT
or
or
the
current
nodes
on
the
network.
We
found
that
57
percent
of
nodes,
apparently
don't
have
any
validators
attached
to
them,
so
they're
either
lying
to
us
or
they
actually
don't
have
validators
attached
to
them
and
they're
not
they're,
not
participating
in
any
of
the
subnets.
A
So
if
we
do
Transition
over
into
this
state,
they
actually
have
to
start
participating
in
helping
out
and
it
lowers
the
bandwidth
for
the
institutional
stakers
or
the
ones
that
have
high
number
of
validators
yeah.
So
essentially,
all
the
beaker
nodes
will
now
contribute
to
to
doing
to
to
helping
with
this
subnet
stability.
So
it
kind
of
sounds
pretty
good
that
we
get
a
massive
reduction
in
bandwidth,
but
there
is
a
cost
and
the
cost
is
how
many?
What
is
the
density
of
of
nodes
that
you
can
find
that
exist
on
these
subnets?
A
So
if
no
one
was
subscribe
to
there,
we
wouldn't
be
able
to
find
those
pairs
in
order
to
publish
publish
our
messages
on
these
subnets.
So
we
still
need
a
decent
density
so
that,
if
you
just
randomly
look
through
the
PSA,
you
can
actually
find
nodes
on
those
subnets
and
kind
of
hold
on
to
them,
and
so
this
graph
here
is
a
distribution
of
the
current
density
and
what
the
density
would
look
like
if
we
switch
to
having
one
and
one
big
node
per
one
topic.
A
So
at
the
moment
it's
it
looks
roughly
like
eight
percent,
so
you
randomly
pick
a
node
there's
an
eight
percent
chance
that
it's
going
to
exist
on
any
given
subnet.
If
we
switch
to
one
Beaker
node
per
one
subnet
it
drops
to
about
one
and
a
half
percent,
which
is
one
on
sixty
four,
as
you
would
expect.
The
benefit
of
that
is
that
it's
configurable,
we
don't
have
to
say
one
bigger
node,
one
subnet.
We
can
say
one
Beacon,
no,
two
subnets
one
bigger,
no
three!
A
So
now
so
we
can
adjust
that
that
kind
of
differential
and
whether
that's
feasible,
is
dependent
on
the
number
of
nodes
on
the
network.
So
that's
something
we
need
to
measure,
but
the
benefits
that
we
get
from
this
is
essentially
for
the
institutional
stakers,
which
represent
roughly,
like
10
of
all
the
validating
nodes
on
the
network.
Their
bandwidth
will
drop
by
about
over
90,
which
is
kind
of
Handy
and,
as
I
mentioned
before,
everyone
that
has
more
than
one
validator
will
have
a
reduced
bandwidth.
So
fundamentally
we're
talking
about.
A
Do
we
need
all
of
these
nodes
on
the
network
to
support
these
subnets
at
the
cost
of
the
huge
amount
of
bandwidth
they're
currently
using
and
so
potentially
not
and
it's
customizable.
The
second
thing
is:
it's
also
enforceable
because
we
would
tag
a
beaker,
node's,
node
ID,
to
a
subnet,
and
so
when
we
connect
to
a
weaker
node-
and
it's
not
subscribed
to
that
subnet-
that
we
know
that
it's
being
naughty
or
relying
to
it.
So
we
can
kick
it
off,
so
we
actually
have
the
enforceability
property
yeah.
A
So
that's
one
solution
and
that's
kind
of
a
low
hanging
fruit.
It's
kind
of
easy
to
do.
We
get
substantial
gains.
The
other
thing
that
Diva
was
talking
about
is
message
amplification
in
gossips
app.
So
if
there's
anything,
we
can
do
about
that.
The
idea
that
we
want
to
try
and
push
forward
is
a
concept
called
appisub.
A
They've
done
a
bunch
of
research
in
particular
viso
or
Dimitri,
who
works
for
protocol
Labs
has
has
had
this
kind
of
vision
for
episod
for
a
while,
but
has
never
had
the
push
or
the
drive
to
do
it,
but
now
that
we're
seeing
quite
substantial
amounts
of
bandwidth,
it's
it's
probably
time
we
try
and
realize
this
thing
so
I
just
want
to
briefly
go
over
the
concept
and
what
it's,
what
it's
going
to
do
and
how
it
could
help
us
with
bandwidth.
Okay,
so
app
is
up
you.
A
What
the
biggest
problem
that
we
have
is
that
if
you
have
a
high
mesh
degree
as
Diva
was
saying
that
that
means
you
have
a
high
connectivity
of
nodes
in
your
network,
so
every
node
could
be
connected
to
another
10
or
eight
other
nodes,
and
then
you
get
huge
message
amplification.
So
every
time
you
send
one
message
most
of
the
network
will
probably
have
to
download
it
eight
times.
A
So
if
you
increase
that
message
by
one
megabyte,
you're
actually
increasing
it
by
eight
times
eight
megabytes,
because
that's
the
amount
of
boundaries
that
has
to
be
downloaded
and
then
propagated,
so
natively,
you
would
first
think,
okay.
Why
don't
we
just
lower
the
mesh
degree?
I
did
try
to
do
that
at
one
point,
but
as
everyone
points
out,
that's
not
very
it's
not
a
safe
thing
to
do.
We
don't
really
know
how
the
network
is
going
to
behave.
A
We
can
try
it
on
test
Nets,
but
the
topology
or
the
structure
of
a
test
net
doesn't
look
like
mainnet.
If
we
just
lower
the
mesh
degree
to
two
for,
for
example,
a
mainnet,
you
might
just
not
restart
receiving
blocks,
so
we
have
to
do
that
with
either
great
care
or
with
a
lot
of
testing.
So
it's
it's
an
interesting
idea,
but
we
could
probably
do
better.
So
another
idea
is
to
dynamically
adjust
adjust
the
connectivity.
A
A
Where
you
receive
your
messages
from
so
that
kind
of
sounds
like
we're
trying
to
win
on
two
fronts:
we
get
less
bandwidth
and
higher
latency,
which
kind
of
doesn't
sound
like
we
should
be
able
to
do
it.
But
let
me
explain
the
the
general
principle
and-
and
maybe
it
makes
sense,
so
the
general
principle
is
you're,
a
node
on
the
network
you're
receiving
all
of
these
messages.
A
lot
of
them
are
duplicates.
A
You
want
to
just
start
collecting
Statistics
over
which
nodes
are
you
sending
you
these
duplicates
and
which
ones
are
sending
you
late
duplicates
and
you'll
end
up
having
some
distribution
of
the
the
number
of
duplicates
you
get
and
the
latency.
So
it
could
be
that
Paul
over
here
in
the
front
constantly
sends
me
some
late
duplicate
three
seconds
late,
whereas
Sean's
sending
it
to
me
straight
away
instantly.
So
I
come
up
with.
A
Essentially
a
choking
strategy
is
what
we
call
it
where
we
look
at
all
of
the
distribution
of
people
sending
us
duplicates
and
the
ones
that
are
late
or
the
ones
that
have
lower
latency
and
we
send
a
message
called
a
choke.
So
in
this
example,
we
say
I'm
going
to
choke
Paul
because
he
is
sending
me
late
messages
all
the
time.
What
the
choke
message
does
is.
It
indicates
to
Paul
to
no
longer
send
me
these
messages
over
the
mesh.
A
Instead,
he
does
a
process
called
gossip,
where
he
just
sends
me
like
the
message
ID,
which
is
a
much
smaller
thing
so
over
time.
If
eventually,
based
on
your
choking
strategy,
you
should
have
a
more
efficient
Mass,
where
you're
only
receiving
the
messages,
with
a
lower
number
of
duplicates,
maybe
from
just
one
or
two
peers
where
the
rest
of
them
are
choked
and
you
still
receive
gossip
from
them.
A
So
if
the
two
peers
that
you
have
in
your
mesh
are
slow
and
the
other
ones
that
you
have
choked
are
started,
sending
you
message
IDs
before
you
send
them
in
the
mesh,
we
have
an
unchoked
message,
so
we
can
uncheck
them
and
put
them
back
into
the
mesh.
So,
ultimately,
the
idea
would
be
is
that
you're
you're
dynamically
changing
your
mesh
and
how
many?
What
peers,
what
peers
are
sending
you
messages
and
how
fast
they're
doing
it
in
order
to
try
and
make
it
essentially
more
efficient?
A
Hopefully
that
makes
sense.
I
take
questions
afterwards.
Does
this
work?
I
guess
is
the
question?
There's
been
some
preliminary
simulations
on
this
as
I
mentioned,
viso
from
lip
P2P
and
protocol
Labs
has
done
a
work
done.
Some
work
on
this
he's
built
a
generic
simulation
from
for
the
Go
version
of
this
with
250
500
and
a
thousand
nodes,
and
so
this
is.
This
is
with
a
mesh
degree
of
six.
So
there's
roughly
about
a
six
times
amplification.
A
If
you
look
at
the
messages
in
these
simulations,
but
pretty
much
in
all
of
the
simulations,
what
this
graph
is
showing
you
is
that
you
get
roughly
a
50
reduction
in
the
duplicates
from
every
sub.
Now,
as
I
said,
there's
a
choking
and
a
non-choking
strategy
which
are
left
somewhat.
Generic
and
I
think
we
can
tune
this
to
be
significant,
especially
if
we
target
it
for
the
ethereum
network.
A
I
think
we
can
get
better
versions
of
this,
but
at
face
value
it
looks
like
you
can
reduce
the
GPS
by
50
just
by
adding
these
kinds
of
messages.
The
next
thing
we
probably
should
talk
about
is
latency
I
kind
of
suggested
that
we
could
get
a
reduction
in
duplicates
and
reduction
in
latency.
The
initial
results
that
visor
has
completed
in
a
simulation
seems
that
the
latency
increases
so
on.
A
The
left
is
Gossip
sub
latency
distribution,
where
the
buckets
are
like
milliseconds,
since
you
received
the
message
and
on
the
right
is
episode,
so
you
we
receive
more
messages
with
higher
latency
in
these
simulations,
but
as
I
was
saying,
these
are
somewhat
generic.
The
the
topology
of
these
does
not
look
like
the
ethereum
network
that
we
have,
and
these
can
be
highly
tuned
to
what
we
need.
A
There's
a
lot
of
like
research
work
going
in
there
there's
a
few
people
in
the
audience
where
I
think
that
I've
promised
results
for
a
mainnet
version
of
this,
so
asset
Sigma
Prime,
we've
built
essentially
a
production
version
of
episode
inside
gossip
sub.
The
advantages
are
that
it's
backwards
compatible,
so
we
can
release
it
in
in
our
clients,
it'll
work
existingly
with
every
other
peer
and
every
other
gossip
sub
node
on
the
network.
But
if
there
happens
to
be
another
episode,
node
on
the
network,
we
can
start
getting
this
bandwidth
minimization.
A
So
the
fact
that
it's
backwards
compatible
is
super
handy.
We
can
kind
of
just
release
it
whenever
we
want
we're,
also
working
on
a
mainnet
simulation,
so
that
we
can
actually
simulate
the
bandwidth
that
exists
on
mainnet
and
then
apply
Fe
sub
and
then
get
essentially
more
specific
data,
that's
more
robust
and
how
we
can
actually
apply
this
to
what
it
would
look
like
on
an
ethereum
two
main
net.
These
will
publish
results
from
this
very
soon
and,
if
you're
interested
just
let
us
know
so,
the
title
of
the
talk
was
reducing.
A
If
I
can
remember,
the
title
of
the
talk
was
reducing
bandwidth
for
institutional
and
homesteakers.
So
if
you're
an
Institutional
or
a
homesteaker-
and
you
came
here
being
like
how
do
I
get
all
these
bandwidth
gains?
What
do
you
need
to
do
in
order
to
get
a
90
reduction?
The
answer
is
nothing
you
just
have
to
wait,
we'll
release
it,
maybe
run
a
lighthouse,
node
and
hopefully
yeah
we'll
we'll
be
able
to
reduce
the
bandwidth.
But
that's
the
end
of
our
talk.
Thank
you.
B
A
B
E
A
E
A
B
The
part
that
matters
for
what
Mark
asked
is
mainly
the
amplification
factor
and
not
that
much
how
it
behaves
regarding
the
number
of
validators.
So
since
we
have
an
amplification
factor
of
about
six,
so
now,
with
this,
this
Improvement
we're
going
to
have
huge
block
sizes
which,
if
we
continue
doing
things
the
way
we
are,
are
going
to
be
sent
across
the
network
six
times
each
time
each
block.
So
that's
that's
insane,
but
there
is
yeah.
So
it's
related
more
about
duplicates
that
part
than
the
number
of
validators
for
each
node.
F
So
you
showed
that
by
modal
distribution,
where
there's
a
lot
of
one
validator
nodes
and
then
there's
that
sixty
percent
that
were
just
regular,
full
nodes
like
not
validators,
and
then
you
know
the
institutional
notes
with
like
more
than
64.,
so
that
I
understand
how
the
Epi
sub
like
helps
everyone,
and
it
like,
helps
the
homesteaker.
It
helps
the
Netflix
problem
for
the
institutional
stakers,
their
all
running,
like
data
center
nodes
anyway.
So
I
I
don't
understand
as
much
how
the
like
subscribing
to
fewer
gossip
sub
topics
helps.
A
So
I
think
I
think
this
is
a
very
similar
question
over
here,
so
I
think
fundamentally,
we
were
looking
at
as
as
a
whole,
the
the
network
may
be
consuming
more
bandwidth
than
we
need
to
be
you,
depending
on
how
how
you
build
your
client,
You,
Can,
Be
Clever,
about
which
peers
that
you
connect
to
when
you
have
so
at
the
moment
you
have
these
institutional
notes.
All
right,
they've
got
that
they're,
not
just
institutional.
Some
people
there's
a
usually
parameter,
I
think
in
most
clients,
which
is
called
subscribe
or
subnets.
A
So
you
can,
even
if
you
have
one
validity,
subscribe
to
all
the
subnets
and
the
reason
you
do.
That
is
because
you
get
some
benefit
from
seeing
all
the
attestations.
You
get
a
slight
increase
in
performance,
so
it's
not
necessarily
just
institutional
people,
but
the
the
institutional
I
forgot.
What
for
my
train
of
thought,
the
no
I
forgot
what
I
was
saying
and
I
just
have
a
point.
It's.
B
Part
of
what
age
was
saying
is
that
well
subscribing
to
a
subnet.
We
also
advertise
that
we
are
inside
the
subnet
inside
Discovery,
so
that
means
that
we
need
to
find
peers
using
discovery
that
are
useful
for
us.
So
one
strategy
that
people
who
have
the
bandwidth
for
that
used
to
be
sure
that
they
have
publishing
all
in
time
and
everything
is
timely-
is
subscribing
to
all
subnets,
regardless
of
how
many
validators
they
have.
This
is
what
age
was
saying
about.
A
Yeah
sorry
I
remember
my
point.
My
point
was
that
we
have
these
institutional,
Stakes
or
people
that
are
subscribed
to
all
the
subnets
and
they
become
more
valuable
than
every
other
node
on
the
network.
If
from
a
client
perspective,
if
you
have
peers
that
are
connecting
to
you
and
one
is
subscribe
to
just
one
subnet-
and
you
have
another
pair
that
subscribe
to
all
64.
A
you're,
more
inclined
to
be
like
I
want
to
stick,
keep
a
peer
connection
to
that
guy,
because
in
case
I
need
to
I
need
to
send
a
message
on
one
of
the
subnets
he's
he's
he
or
she
is
connected
to
that
subnet.
So
you're
left
with,
like
10
of
these
nodes,
are
super
valuable
nodes
across
the
network,
whereas
everyone
else
you
kind
of
just
throw
them
away.
They're,
not
they're,
not
all
that
valuable,
whereas
if
we
transition
over
to
this
thing,
one
it's
enforceable,
which
is
something
that
we
want.
A
Two
we're
not
entirely
sure
whether
the
amount
of
banter
for
using
across
the
entire
network
is
necessary.
So
we
reduce
that
as
a
I
guess,
maybe
a
side
effect
and
the
the
third
example
is
that
all
be
all
the
nodes
are
equally
kind
of
valuable
to
you
and
because
we
tie
it
to
the
node
ID
it
makes
the
node
ID
specifies
which
subnet
they're
supposed
to
be
subscribed
to.
So
when
we're
doing
Discovery
queries,
we
can
actually
search
more
efficiently
for
nodes
on
a
specific
subnet,
because
it's
tied
to
that
node
ID.
A
G
Cool
could
talk
to
you
guys
thanks.
So
you
mentioned
reducing
bandwidth
and
reducing
latency
to
like
avoid
missing
expectations,
something
that
we've
looked
at
as
well
is
like
affecting
the
effectiveness
ratings
with
validators.
Can
you
guys
speak
which
can
result
in
like
penalties
or
loss
reduction
in
rewards?
Can
you
guys
speak
to
how
this
would
help
with
effective
Effectiveness
ratings,
if
it
would
which
I.
A
I
guess
the
first
one
is
kind
of
what
I
introde
with
my
my
personal
attestation,
Effectiveness
drops
when
someone
watches
Netflix,
so
I.
Imagine
for
a
lot
more
homesteakers
that
are
kind
of
on
the
bandwidth
limit
or
their
upload
speed
is
quite
low
like
in
like
in
Australia,
and
we
reduce
the
bandwidth
requirements.
A
We
find
that
that
there's
a
number
of
Main
that
that
impact
the
attestation
efficiency
and
that's
one
is
bandwidth
and
the
other
one
is
CPU
limitation
flight
processing.
So
if
you're
running
a
a
node,
that's
overburdened
and
and
this
the
topic
subscription
is
another
thing
that
can
overburden
a
node,
because
if
you're
subscribed
to
a
lot
of
notes,
let's
say
you
have
five
validators
attached
to
you
and
you
have
five
Long
Live
subnets.
You
have
to
get
all
the
messages
and
you
have
to
process
them.
A
H
H
B
B
Is
explicit,
so
I
know
this
is
actually
going
to
know
it's
going
to
be
showed
we're
asking
him
to
stop
sending
messages
to
us.
It's
not
yeah.
You
know
it's
I
know
it
sounds
similar
to
what
is
happening,
for
example,
in
in
strategies,
for
example
in
I.
Don't
know,
follow
sharing,
but
it's
different
in
the
sense
that
we're
the
ones
asking
the
peer
to
just
stop
sending
the
messages,
so
it's
kind
of
a
benefit
for
them.
So.
A
A
We
know
that
it's
supposed
to
be
subscribed
to,
let's
say
topic,
three:
the
way
that
we,
when
we
connect
via
gossip
sub,
they
should
send
our
subscriptions
about
what
it's
subscribed
to
and
and
if
it's
not,
if
it's
not
subscribed
to
that,
we
know
that
it's
being
malicious
or
faulty
straight
away,
and
we
can
just
disconnect
it.
There's
technicalities
where
I
can
say
that
it's
subscribed,
but
then
won't.
Let
us
so
the
next.
The
next
phase
of
the
thing
is
we
try
and
create
a
mesh
mesh
Network.
A
So
if
we're,
if
we're
connected
to,
let's
say
100
pairs,
we
only
really
form
a
mesh
with
with
the
mesh
degree
with
like
three
of
them.
So
in
principle
they
could
always
just
say.
No,
no,
you
can't
go
on
my
Mash.
You
can't
call
my
mesh
I'm,
full
I'm,
full
I'm
full.
So
that's
one
way
to
kind
of
grief
Us.
In
that
scenario,
they
still
have
to
forward
us
gossip
sub
messages.
A
There's
a
there's,
a
small
mechanism
inside
gossip
sub,
that
is
called
gossip,
subscribing
as
you
just
in
1.1,
which
somehow
mitigates
attempts
to
mitigate
censoring.
So
where,
where
you
just
say
that
you're
subscribe,
you
do
nothing
and,
and
the
whole
network
essentially
tries
to
kick
you
out
of
the
mesh
in
terms
of
while
being
choked.
We
only
choke
people
that
are
in
our
mesh,
so
only
people
that
are
subscribed
and
then
once
they've
grafted
with
us.
So
we
form
this
mesh
connection,
which
means
they
have
to
be
subscribed.
A
They
have
to
be
sending
us
messages
if
they're
not
sending
us
messages,
1.1
scoring
we'll
kick
them
out,
and
then
we,
then
we
choke
or
unchoke
them
in
order
for
them
to
be
malicious
and
try
and
cheat
that
system
they're,
choking,
abstract
the
choking
strategy
is,
is
abstract
and
can
be
implemented
independently
on
each
node.
So
you
don't
know
on
each
of
your
peers
what
what
is
specifically
their
choking
strategy.
They
could
just
pick
random
nodes
on
their
mash
and
choke
people.
So
I
think
there
is
an
Avenue
of
security
to
to
look
in
there.