►
From YouTube: Node Operator Roundtable - June 21, 2023
Description
This week, the EOS Node Operator Roundtable discusses Peer 2 Peer Improvements, Block Logs, Bandwidth Consumption, Sync Improvements, Feedback and Solutions, and much more!
00:00:00 Start
00:00:10 Leap Software Development Update
00:02:57 Peer 2 Peer Improvements
00:11:40 Block Logs
00:22:10 Bandwidth Consumption
00:28:59 Peer 2 Peer Sync Improvements
00:49:16 Feedback and Solutions
00:57:14 End
The EOS Network Foundation coordinates financial and non-financial support to encourage the growth and development of the EOS Network. We’re harnessing the power of decentralization to chart a coordinated future for the EOS Network as a force for positive global change.
// EOS Network Foundation //
https://www.eosnetwork.com
https://twitter.com/EosNFoundation
https://www.linkedin.com/company/eos-network-foundation
https://t.me/EOSNetworkFoundation
https://discord.gg/eos-network
info@eosnetwork.com
#EOS #Web3
B
C
B
We
had
a,
we
had
an
issue.
Actually,
maybe
Kevin
can
talk
about
the
issue
in
the
fix
it's
ready
to
go.
We
just
need
to
hit
the
big
red
button
on
the
release,
so
basically
right
after
we're
done
with
this
call,
I'll
be
hitting
the
big
red
button
and
there
will
be
a
4.03
release
available
for
upgrade.
C
C
C
C
Is
that
a
lot
of
the
theme
of
how
we're
trying
to
unpack
this
is,
of
course
introducing
more
like
visibility
or
observability
into
what
we
believe
is
important,
starting
with
logging
and
then
after
that,
of
course,
starting
to
wrap
material
Ways
by
which
we
could
actually
manage
any
of
the
things
such
as
peer
Behavior
or
how
much
bandwidth
we
may
be
affording
to
our
peers,
etc,
etc.
So,
without
any
further
Ado
I'll
start
sharing.
My
screen
I'll
briefly,
walk
through
the
dock.
C
I
promise
I'm
not
just
going
to
read
it
wine
for
a
line,
but
there
are
a
couple
of
headlines
that
are
worth
talking
about
and
then
I
did
have
a
couple
of
clarifying
questions
that
I
was
interested
in
digging
into
with
this
group
Daniel.
If
you
have
a
moment,
could
you
give
me
screen
sharing
access,
foreign.
C
Perfect,
thank
you
all
right.
So,
as
stated,
the
link
is
there
in
the
zoom
chat.
If
you
need
it,
maybe
something
quickly
that
I'll
mention
is
that
a
lot
of
the
conventions
that
we're
trying
to
adopt
and
have
been
trying
to
observe
as
the
product
team
at
the
enf
is
having
a
lot
of
our
initiative
and
Epic
Level
materials
living
inside
of
this
enf
product
repo.
C
This
is
also
we've
managed
some
historical
proposals
that
have
come
through
in
the
form
of
PRS,
but
it's
also
how
we'll
hopefully
be
working
too,
of
course
outline
the
problems
that
we
believe
are
opportunities
to
tackle
and
then
have
some
subsequent
work
breakdown.
That's
linked
back
to
these
items,
so
this
is
just
a
bucket
observing
those
P2P
improvements
and
a
lot
of
where
I
wanted
to
start.
C
The
discussion
and
get
some
feedback
on
today
is
just
how
good
of
a
job
we
did
internally
capturing
the
problems
that
we
believe
we're
facing
as
node
operators
as
it
pertains
to
P2P.
So
the
first
big
item
that
we
had
discussed
in
previous
meetings
was
just
this
need
for
an
improved
catch-up
mode,
peer
selection
ability.
C
So
the
core
problem
was
that
I
as
a
node
operator,
don't
necessarily
have
connections
to
peers
that
have
the
data
that
I
need
and
there's
a
lot
of
waste
that
occurs
in
attempting
to
get
that
information
from
a
respective
peer,
as
was
mentioned
in
previous
discussion,
that
works
actually
already
been
accomplished
via
some
work.
That
Kevin
did
that's
of
course
linked
here
that
we
can
dig
into
and
we'd
appreciate
some
feedback
on.
I,
don't
think,
there's
too
much
extra
discussion
around
this
one's,
pretty
straightforward
problem
of
my
peers.
C
C
The
work
that's
not
been
done
yet
that
we
believe
is
the
next
highest.
Priority
is
just
better
controls
around
peer
bandwidth
consumption,
so
node
operators,
of
course
need
to
be
able
to
support
the
network
without
experiencing
any
abuses,
or
ideally
as
few
as
possible
in
terms
of
things
like
bandwidth,
consumption.
C
There
was
also
some
discussion
about
maybe
some
other
ways
we
may
want
to
tag
or
label
things
that
we
are
interested
in.
Exploring
but
this
is
really
where
things
started
and
then,
of
course,
something
else
that
we
discussed
related
to
this
topic
was
just
that
there
are
some
concerns
around
how
we
might
be
able
to
actually
identify
in
group
peers
based
on
the
fact
that
they
may
be
coming
through
a
load
balancer
and
that
may
be
challenging
for
us
to
detect.
C
C
C
The
reason
why
we're
not
prioritizing
this
outright
is
that
we
believe
that
having
greater
controls
around
bandwidth,
consumption
is
kind
of
that
top
top
thing.
And
then,
after
that,
we
may
have
some
more
Discovery
around
how
critical
it
is
to
actually
be
able
to
monitor
some
of
these
other
forms
of
behavior.
That
may
be
impactful
to
the
stability
of
P2P.
So
last
little
thing
here
that
we
had
outlined
beyond
that
is
just
improved
management
of
available
sinkable
blocks.
So
some
of
the
discussion
that
happened
here
was
really
just
around.
C
Maybe
this
desire
to
have
a
specific
Lucas
of
state
that
we
wish
to
make
available
or
a
specific
range
of
blocks,
and
this
may
or
may
not
be
related
to
some
of
the
block
log
splitting
functionality
it's
been
introduced.
It
wasn't
quite
clear
at
the
time
how
much
that
intersected,
but
this
is
another
thing
that
we're
interested
in
looking
into,
but
we
believe
we
should
start
with
sort
of
those
top
three
or
four
that
had
been
discussed
prior
to
this
any
questions
or
comments
around
this
next
batch
of
three
kind
of
header
level.
E
Yeah,
the
idea
of
the
improved
management
of
the
available
syncable
blocks
is,
like
you
said
also
part
of
it.
Is
that
splitting
of
block
log,
because,
as
chains
grow,
you
don't
want
necessarily
store
everything
on
super
fast
nvmes.
You
want
to
make
your
old
block
logs
on.
You
know
just
platter
big
drives,
maybe
even
room
like
you
know,
on
another
kind
of
shared
folder
on
on
your
data
center
they'll
be
slow
to
access,
but
you
don't
but
fast
for
somebody
internal.
E
So,
for
example,
you
want
your
internal
nodes
to
be
able
to
access
all
these
blocks
when
they
need
to
sync
from
scratch
or
your
history
solution
when
it
needs
to
pull
those
blocks.
But
you
definitely
don't
want
to
serve
these
because
it's
just
going
to
make
a
bottleneck
on
your
on
your
slower
drives.
C
C
This
call
to
date,
at
the
intersection
of
using
this
feature
of
things
like
block
log
splitting,
wherein
we
actually
are
storing
on
some
sort
of
slower
storage
solution
and
that
actually
introducing
bottleneck
and
pain
for
you,
as
a
node
operator,
I'm
interested
to
know
a
little
bit
more
about
how
real
this
has
been.
For
you
thus
far
doesn't
mean
that
it
it's
not
real,
but
I'm
interested
to
know
like
have
we
run
into
this.
Are
people
using
this
feature?
D
So
I'd
like
to
maybe
open
up
a
conversation
here,
yeah
the
block
slog
is
is
not
like.
It
doesn't
have
the
same
kind
of
eye
requirements
as
that's
the
the
state
folder,
but
the
block
slug
has
got.
Obviously
it's
the
it's
a
complete
log
of
all
of
the
the
blocks
from
from
the
chain,
depending
on,
if
you're,
a
full,
node,
etc,
etc.
However,
the
block
slog
is
still
used
for
certain
lookups,
even
from
a
straight
up,
V1
chain,
nodius
level.
D
So
if
I
did
a
get
block,
it
would
be
looking
at
my
block
slog
for
some
of
that
some
of
the
data
and
then
manages
to
read
it
from
that
from
that
data.
What
we
found
when
we,
when
we
are
you
know
providing
API
services
to
like
massively
busy
chains
I.E,
the
one
massively
busy
chain,
which
is
wax
block
slot,
can
easily
be
stored
on
a
Spinning
Disk
and
probably
the
only
time
that
that
I
can
see
either
other
than
if
anybody
can
say.
D
D
D
I've
got
some
that
aren't
full
they're,
just
like
running
there
inside
of
an
nvme
or
an
SSD
or
whatever,
but
I,
don't
I,
don't
I,
don't
I've
never
ever
hit
the
wall
where
the
block
slug
is
not
on
the
NVM
being
or
on
the
SSD
or
solid
state
disk
or
whatever
that
it
has
been
a
problem.
But
and
do
you
know
there
are
certain
queries
that
need
that
block
slog
and
I'm
not
entirely
sure?
What
are
those
queries?
And
maybe
you
have
someone
went
and
did
like
a
you
know,
a
hundred
thousand
get
blocks.
D
Maybe
suddenly,
then
my
Spinning
Disk
arrays
are
not
going
to
handle.
I
can
tell
you
what
doesn't
hail
like
the
the
state
folder
with
the
real-time
memory
mapping
that
can't
handle
on
a
really
really
high
performance
chain
that
that
can't
handle
on
the
spinning
disc.
That's
all
I
can
say
so.
So
it's
a
bit
of
a
conversation
here,
I'm
putting
up
you
know
what
I
mean
I.
E
Think
outside
the
this
point,
that
yes,
of
course,
if
you
have
one
node
just
reading
it
sequentially
in
a
way
yeah
I,
don't
think
you're
going
to
have
much
effect.
But
if
you
have
a
bunch
of
peers
trying
to
get
blocks
out
of
different
parts
of
the
block
log
at
the
same
time,
I
think
you
might
run
into
that
issue.
That.
E
Is
an
additional
bigger
issue,
I
think
of
bandwidth
where
somebody
might
be.
You
know,
for
whatever
reason,
just
seeking
all
the
blocks
all
from
you
and
you
might
for
whatever
reason
you
might
not
want
to
have
somebody
sync
from
block
one.
You
want
to
only
have
that
for
your
own
nodes
through
your
bandwidth,
it's
not
going
to
handle.
You
know
like
many
people,
thinking
yeah
from
Genesis,
so
it's
more
really
just
control
on
other
people
being
able
to
use
that
resource
of
yours,
whether
it's.
G
G
G
When
you
put
some
restrictions
in
at
the
operator
level,
it
gave
us
the
the
two-fold
ability
one
us
to
limit
at
a
certain
level
of
you
know
how
much
you
could
rip
off
of
us
before
we
say
nah.
You
should
probably
take
a
break
and
that
then
piggybacking
off
of
the
node's
natural
tendency
to
be
like
that's
cool
you're,
either
down
or
I've,
reached
some
limit
that
you,
you
specified
I'll,
go
ahead
and
move
to
the
next
one
versus
trying
to
have
the
the
syncing
node.
You
know
systematically.
G
Don't
piss
them
off
only
think
this
much
from
them
yeah
think
until
they
tell
me
not
to
but
then
kind
of
systematically
roll
through
to
help
address
this
man.
You
only
really
need
one
or
two
peers
to
think
effectively,
but
then,
if
one
of
them
goes
down
or
if
you're
lost
and
just
get
ripped
on,
for
you
know
a
gigabit
Non-Stop
and.
G
A
D
E
Like
one
of
our
databases,
we
try
to
basically
compute
the
incremental
Merkel
3
at
each
block
height,
and
that
that's
really
all
I
need
is,
is
the
block
ID
so
not
even
get
before
I
used
to
use,
get
Block,
but
now
I'm,
just
using
like
Dead
Block
default,
and
even
that,
if
you
send
like
simultaneous,
you
know
like
over
800.
Of
course
it's
not
your
traditional
user,
but
if
you
send
like
that
much,
it's
just
gonna
break
no
deals
like
clearly.
E
You
know
yours,
just
pauses
and
stalls,
okay
have
to
restart
the
node
itself,
so
I
can
only
imagine
what
get
Block
would
do
at
if,
if
you
do,
those
like
basically
promise
based
where
they're
all
sent
at
once
and
you're
doing
kind
of
like
a
promise
all
on
it,
I
believe
that's.
That
is
still
an
issue,
but
I'm
not
sure.
If
that
is
the
bottleneck
is,
is
the
hard
driveway
there?
You
know
it.
D
G
H
E
A
B
G
Not
sure
if
it's
related
to
the
operator
side
or
the
we
call
it
I'll
call
them
the
dev
side.
You
know
the
the
not
public,
Emperor
operator,
I.
Think
part
of
the
availability
of
six
blocks.
I
mean
it
plays
into
the
node,
expects
every
peer
to
have
whatever
everything
asked
for
and
it's
very
inefficient
if
it
doesn't
have
it
because
it
doesn't
roll
to
the
next
one
so
yeah
it
was
like.
For
instance,
you
talk
about
the
bandwidth
consumption.
G
Yes,
once
you
rip
two
gigs
a
day
off
of
me,
I
want
to
tell
you
to
go
away,
but
if
I
don't
have
the
block
logs
or
if
a
block
log
a
node
operator
doesn't
have
that
block
log,
the
peer-to-peer
says:
hey
I'm
here:
nope,
don't
have
what
you
need,
but
the
the
current
architecture
just
keeps
asking
the
same.
You
know,
even
though
both
sides
ultimately
know
every
single
query:
yeah,
that's
not
going
to
be
that
data.
Is
there
it
ties
into,
but
it's
separate
I
mean
it.
G
It's
part
of
looking
at
the
whole
peer-to-peer,
optimization
and
different
mechanisms
actually
kind
of
play
into
different
solutions.
You
know
it's
not
just
one-to-one
which
typical
right,
but
it
has
to
do
with
one
streamlining
the
the
syncability
of
a
new
node,
because
when
it
grabs
hold
of
one
there's
no
way
yeah
and
no
until
after
the
fact.
Nor
can
it
even
ask
to
say
unappeared
people.
D
G
I,
don't
know
correct,
I
mean
and
that's
what
so,
it's
not
just
one
block.
But
again
if
the
peer-to-peer
respond
was
to
say
hey
just
like
the
get
Block
y'all
added
it
to
gitblock
and
it
made
life
a
lot
easier
for
people
to
be
like
the
node.
Isn't
a
full
node,
don't
expect
it
to
be
one,
but
on
the
peer-to-peer
level
there
wasn't
that
and
then
that
played
into
the
inefficiencies
of
aren't
you
going
to
try
any
of
the
others.
No
I
only
gave
you
two
because
if
I
have
10,
it
makes
it
slower.
E
Of
that,
so
so
part
of
a
new
change
is
Kevin
mentioned
there.
On
the
last
calls
where
you
know
now,
you
have
where
you
define
the
maximum
peers
you
want
to
connect
to,
and
you
can
provide
like
a
longer
list
and
then
say
you
want
to
only
connect
to
the
top
five
peers
in
terms
of
latency
and
block
availability.
It
attains
that,
but
I
think
the
concern
with
it
still
is
that
it's
still
every
you
know
like
I,
don't
know
a
second
or
a
few
seconds.
E
It's
gonna
do
another
handshake
to
to
figure
out
the
number
of
blocks
available
for
each
peer
outside
that
top
list.
So
if
you
have,
you
know,
20
tiers
you're
still
going
to
suffer
that
slow
down
as
well
as
it
will
continuously
check
the
latency
of
each
of
those
peers.
Even
though
they're
they
don't
make
it
to
the
top
list
to
try
to
readjust
the
list.
I
think
what
makes
sense
is
like
it
just
needs
to
kind
of
scan,
for
you
know,
maybe
double
the
amount
of
whatever
Max
appears
you
have.
E
Even
if
you
have
a
period
list
of
you
know
whatever
100
and
and
then
slowly
like
some
that
have
really
bad
latency
or
low
blood,
never
even
tries
them
again
unless
it,
unless
the
top,
10
or
top.
You
know,
Max
peers,
you
set
times
two
list
has
other
issues
and
then
it
can
go
to
the
next
one
to
retry.
D
C
The
mic
over
to
to
Kevin
right,
quick
I
think.
Can
you
clarify
what
of
what
has
just
been
surface
has
been
resolved
because
I
know
that,
like
the
shared
amount
of
data
being
passed
back
and
forth
is
something
that's
fixed.
I
know
that
we
do
have
some
fixes
in
place
to
rotate
through
what
I
was
less
certain
of
I'm.
Just
pleading
ignorance
here
is
when
it
comes
to
specifically
requesting
a
specific
Block
versus
a
range
of
blocks.
H
Sorry,
my
dogs
are
going
nuts
I
Heard.
Most
of
that
I
think
so.
Watson
4.0
is
a
fixed
to
the
the
echo
back
of
the
block.
So
now
that
fix
has
not
been
back
ported
because
the
fix
was
part
of
a
larger
change
of
better
tracking
of
blocks,
an
optimization
of
the
internal
block
tracking
within
node.
So
it
was
an
documentation
that
turned
out
to
be
even
better
of
an
optimization
than
I
thought
because
it
fixed
this
Echo
back.
H
H
You
can
configure
a
bunch
of
peers
like
I,
just
grabbed
a
giant
list
and
threw
it
in
my
my
config
that
out
and
actually
remain
that,
and
then
the
default
is
the
top
three
peers,
of
course,
change
that
there's
a
new
setting
there
and
then
it'll
just
it
as
it
discovers
latency
on
node
it
things
can
move
into
those
three
top
three.
It
doesn't
actually
do
that
discovery
of
of
latency
all
the
time
there.
H
There
is
a
kind
of
a
heartbeat
every
10
seconds,
I
believe
it
is
that
it'll
do
across
across
the
notes,
but
even
that
it
won't
do
if,
if
it's
continuously
receiving
like
transactions,
are
blocked
from
those
nodes.
So
like
only
if
there's
kind
of
some
idle
time,
it's
a
hard
boot
clear
thing,
but
on
think
up
it
should
calculate
latency
and
use
that
it
also
other
do
you
protocol
now.
H
Unfortunately,
this
does
require
a
protocol
change
in
the
network
again,
and
so
when
the
when
the
net
plugin
is
speaking
to
older
Peters,
it
won't
know
what
its
range
is.
Only
the
newer
appears,
the
4.0
peers
can
communicate.
Hey
here's
my
range,
and
so
once
it
knows
the
range,
if
it's
thinking
it
it
will
it'll
skip
over
like
well
I
can't
use.
It
knows
that
it
can't
use
these
because
it
doesn't
have
those
ranges
for
when
it's
communicating
to
3.x
years
that
doesn't
have
that
protocol
feature
that
communicates
what
its
range
is.
H
It
will
try
once
and
it
should
only
try
once
of
saying,
hey
I
need
this
I
need
this
data
and
it'll
say
sorry:
I
don't
have
that
data,
and
then
that
should
get
out
of
that
range
of
default.
Three
assuming
there's
at
least
three
4.0
Piers
that
it
can
find
that
have
that
information?
If
not,
it
will
degrade
back
to
kind
of
3.0.
The
3.x
behavior
a
black
well
just
have
to
keep
trying
these
peers
until
I
find
somebody
that
that
will
answer
me.
D
So
I,
just
wanna
I,
just
want
to
say
something
we
can
test
on
test
nets.
All
we
want,
but
the
most
busy
chain
is
absolutely
wax
and
where
we
are
at
the
moment
is
RP
running
running
for
on
the
wax
testing
it
yeah,
whatever
it
doesn't,
actually
get
a
real
trial
by
fire,
and
this
I
put
it
on
one
of
the
public
apis
and
those
things
are
doing
40
to
50
million
requests
a
day.
D
The
reason
why
I'm
still
running
three
is
that
we
seem
to
have
an
issue
with
four
four,
so
four
zero
one
had
that
had
a
four-headed
bug,
four
zero
one
was
the
fix,
then
402,
camera
402
has
just
got
a
little
bag
and
I
really
want
to
test
all
this
awesomeness
and
I'm
kind
of
just
being
held
back
by
these
little
yeah
and
I
know
that's
not
all
the
stuff,
so
I
just
want
to
know
like
when
when's
it
going
to
happen.
So
I
can
just
get
it
going.
Yeah.
H
The
402,
which
you
know,
was
kind
of
mentioned
at
the
beginning
of
the
call,
and
no
we
didn't
actually
address
that
so
the
402
bug
seems
to
be
at
least
in
my
testing
not
applicable
to
about
220..
It
seems
to
be
applicable
to
other
types
of
containers
or
or
Hardware
that
were
in
play,
so
at
least
on
Ubuntu
20.
H
I
I
was
not
able
to
reproduce
the
issue
there.
The
issue
there
being
I,
don't
think
we
even
mentioned
with
the
issue
was
the
issue
was
that
it
would
disconnect
when
it
inappropriately
so
it
would.
It
was
an
internal
time
calculation,
so
on
some
Hardware,
apparently
the
the
time
resolution
is
not
in
nanoseconds
which,
on
Ubuntu
and
other
testing
garments,
it
is
nanosecond,
clock
tick,
tie
apparently
in
in
some
environments.
That's
not
the
case.
H
It
must
be
like
microsecond,
clocking
clock
tick
time,
in
which
case
that
threw
off
a
calculation
we
put
in
in
terms
of
calculating
when
we
need
to
give
up
on
a
pier
So.
Eventually,
no
youth
will
say
hey.
This
connection
is
Idle,
I
need
to
like
close
it
and
reestablish
the
connection,
because
I
may
be
in
some
sort
of
coma
and
so
Michael.
H
G
H
One
that
was
that
and
so
403,
which
should
be
coming
out
of
a
week
today,
I
think
along
and
say
that
yeah
yeah.
So
then
the
that
calculation
has
been
fixed
on
on
every
Hardware.
It
doesn't
really
matter
what
your
clock
tick.
The
resolution
is
at
this
point
once
that
fix
goes
in,
but
again
those
the
thing
to
only
be
on
certain
hardware
and
certain
situations
that
that
actually
exhibited
itself.
D
And
that
seems
to
be
the
only
tricky
snap
that
we've
had
ahead
with
with
402,
so
you're
going
to
get
a
real
trial
by
fire.
Now,
as
we
start
to
roll
this
out
across
all
of
the
max
the
wax
apis,
it's
going
to
like
really
show.
If
there's
anything
and
we
and
hopefully
we'll
see
the
benefits
of
all
this
pairing
stuff,
yeah.
H
I
I
yeah
again
we'd
love
to
see
that
that
feedback
on,
like
particularly
API
node,
did
you
give
it
some
some
of
those
read-only
threads
and
that
kind
of
stuff.
You
know
configure
that
around
what
you
expect
and
what
you
can
handle
I
mean
that
would
be
very
cool
to
get
you
feedback
there.
I
will
say
like
if
you're
not
running.
H
H
G
G
I,
don't
know
I'm
playing
with
all
the
different
options.
Now,
that's
I
did
some
fresh
loads
of
20,
and
you
know
Works
beautifully
I
got
some
409s
running,
but
yeah
now
I've
got
these
nodes
that
and
here's
the
kicker
is
that
there's
so
many
chains
that
are
still
running
two
or
even
three
that
you
know
custom
builds
that
now
I
can't
get
those
or
get
a
fight
to
get
those
working
out
of
one
two.
Twenty
and
now
I
got
these.
G
G
Aware
and
interested
all
of
them,
I
think
are
aware
and
interested
but
yeah
when
you,
when
you
hack
up
your
your
binaries,
that's
what
now
it
takes
a
whole
and
of
course
now
there's
just
two
and
that
three
hit,
and
now
four
is
here.
So
it's
like
this
will
be
interesting,
but
they're
gonna
roll
three
and
then
we're
gonna
be
right
behind
on
four
again.
G
G
G
E
Yeah
my
coat
for
just
so
you're
happy
for
ux
Network.
We
we
have
a
kind
of
a
private
test
net
with
our
system
contracts,
what
our
cash
changes
running
for
4.0.2
and
now,
of
course,
we'll
upgrade
4.0.3,
and
once
everything
is
fully
tested,
we
will
migrate
the
public
test
net,
that
we
have,
that
you're
part
of
to
the
new
binary
and
then
move
on
to
the
main
net.
E
With
all
the
activated
features
that
are
available
on
yours,
main
Network,
including
action
return
value
and
so
on,
and
just
to
let
you
know
just
a
comment
you
made
about
the
whether
you
need
to
build
your
own
version
3
for
20
to
upgrade
to
downgrade
version.
3
of
sleep
is
available
as
binaries
for
420
as
well.
G
A
G
D
G
C
C
C
That
might
be
my
request
and
then,
where
all
stares
from
here
is
I
did
have
a
couple
of
open
questions
before
we
talk
about
the
work
that
we're
planning
to
do,
because
we
actually
are
going
to
do
something
about
this,
believe
it
or
not.
So
we
already
talked
about
the
use
cases
for
management
of
available,
sinkable
block
ranges
so
I.
Don't
really
think
we
need
to
discuss
that
too
much.
C
One
question
that
we
just
had
anecdotally
and
I
may
keep
it
short
for
the
conversation
here
since
we're
short
on
time,
but
we're
just
interested
to
know
whether
there'd
been
much
consideration
of
throttling
as
an
option
of
bandwidth
management.
I.
Think
that
a
lot
of
like
the
discussion
has
been
sort
of
like
this
binary
of
like
either
you're
like
allowing
people
to
sync
or
you're,
not,
but
there's
not
been
a
lot
of
historical
discussion
around
using
throttling
as
a
strategy.
C
H
Yeah,
so
the
the
idea
that
here
being
of
course,
we
can
do
some
sort
of
we
can
do
some
throttling
at
the
at
the
protocol
level.
In
terms
of
like
you
know,
if
there's
a
lot
of
bandwidth
issues,
the
first
thing,
of
course
we
could
stop
doing
is,
is
traversing
transaction
or
maybe
all
transactions,
and
then
you
know,
fill
an
issue
or
the
other
kind
of
communication.
H
There
is
syncing
right,
and
so
the
idea
is
that,
if
someone's
thinking
from
you,
you
know
you
could
slow
down
the
number
of
blocks
you're
giving
them
over
time.
You
know
just
as
quickly
as
you
can,
when
some
someone's
seeking
from
you,
then
you
could.
You
could
throttle
that
by
you
know
a
block
every
you
know
whatever
half
second
I
mean.
That
would
be
crazy,
but
you
know
whatever
you
could
you
could
slow
that
down
now?
I
Well,
I
mean
thralling
would
be
better
than
disconnecting.
Probably
unless
somehow
the
pier
that's
okay,
well,
I
mean
there's
a
case
for
disconnecting.
If,
like
the
peer
is
sending
you
to
hold
garbage
here
is
a
block.
This
is
like
unlinkable
blocks.
You
know
this
is
not
a
formatted
blog.
This
is
you
know
in
that
case,
like
this,
pier
is
like
trying
to
break
my
note
right.
I
So
there's
a
case
there
for
well
just
kick
them
off
and
put
them
on
a
list
that
they're
not
allowed
to
connect
again
right,
but
you
know
I
think
from
a
normal
peer-to-peer
thinking
like
Michael
was
outlining
earlier.
Oh,
they
already
downloaded
two
terabytes
of
stuff,
so
slow
down.
You
know
I,
think
that's
a
reasonable
request
and
I
think
I
see
that
in
other
appeared.
Well,
if
you
look
at
something
like
BitTorrent,
the
more
you
share
or
make
available
the
more,
you
can
download
kind
of
thing
right.
I
So
if
you
just
suck
everything
and
you're
not
sharing
anything
well,
you
know
I'm
likely
to
give
you
less,
which
is
always
a
problem
from
you
know.
The
initial
sync
I
don't
have
anything
I
need
to
connect
to
somebody.
Please
help,
but
I
can't
share
anything
and
then
well
you're,
not
being
sharing.
So
kick
you
up
right
so
anyway,
you
gotta
worry
about
that,
but
otherwise,
yes,
I'm
protocol
that
limits
the
the
abuse
would
be.
E
G
D
Think
I
think
that
when
there's
I
mean
from
Mike
feeling
on
this
feeling
is
that
when
there's
so
many
peers,
it's
almost
like
there's
excess
processing
on
sending
data
to
those
peers
and
if
there
are
less
peers,
even
though
the
bandwidth
doesn't
change
so
like
sorry,
I'm
I'm
putting
this
against
the
bandwidth
so
like,
let's
say
I'm
using
100
Meg
and
if
I
load
the
pairs,
it
might
still
be
like
you
know,
80
Meg
whatever,
but
the
node
seems
to
use
less
CPU.
It
seems
to
operate
a
little
bit
better.
D
You
know
so
I'm,
not
sure
if
it's
a
banner
thing,
a
number
of
Po
thing
or
a
number
of
piercing
or
like
a
CPU
thing,
you
know
I'm
not
not
quite
sure
all
I
know.
Is
you
lower
that
when
you
go
and
set
your
threshold
lower?
Suddenly
your
node
sites
working
better-
and
you
can
pick
this
up
on
a
test
net
right
where
you've
got
everything
running
on
the
same
node.
You
know
rock
producer
API,
whatever
whatever
and
you
lower
the
lower
the
amount
appearance
that
you
can
have.
D
C
I
C
Well,
a
very
specific
4.x,
yeah,
no
I
think
that's
all
valuable
feedback
in
really.
What
we're
trying
to
accomplish
in
this
meeting
today
is
just
a
line
around
the
priorities
of
what
we
believe
we
should
do
next,
so
we're
already
saying:
well,
hey
guys.
We
already
did
something
here
so
give
us
some
feedback
before
we
do
more
work
on
this
specific
topic.
C
So
that's
why
we
believe
that
bandwidth,
consumption
controls
and
visibility
is
the
next
big
thing
quickly
from
there.
I
did
have
one
other
question:
I!
Don't
think
that
we
need
to
discuss
it
too
much,
but
what
we're
looking
at
since
we
were
talking
about
basically
doing
this
terminal
based
UI
tool
for
managing
in
monitoring
P2P.
There's
just
some
discussion
around
how
relevant
cliosnet
connections
report
May
remain.
I.
C
Don't
think
that
we
need
to
talk
about
this
at
this
point
and
I
think
once
we've
actually
delivered
that
solution,
we
can
better
evaluate
whether
these
things
both
need
to
continue
to
be
used.
But
that's
the
primary
discussion
for
now
I
think
the
last
place
I
just
wanted
to
direct
us
in
the
last
few
minutes
that
we
had
is
as
I
had
mentioned.
Our
objective
is
product
at
the
eanf
is
to
maintain
a
lot
of
these
initiative
and
Epic
Level
items
inside
of
the
product
repo.
C
So
I
just
wanted
to
direct
you
guys
to
inside
of
that
link,
I
provided
at
the
beginning
of
the
meeting.
There's
now
some
task
breakdown
here
that
I
just
wanted
to
blast
through
and
mention
where
we're
headed
from
here
and
what
you
can
expect
from
us
next.
So
the
first
thing
that
we're
doing
is
talking
about
that
visibility
and
monitoring,
so
we're
introducing
Prometheus
logging
for
the
following
P2P
peer
connection
attributes.
C
This
is
kind
of
the
first
thing
that
we're
looking
to
expose
in
that
kind
of
let's
measure
and
learn
from
that
before
we
wrap
additional
functionality
around
management
and
then
moving
on
from
there.
We
believe
that
the
next
thing
that
may
introduce
a
lot
of
value
is
just
allowing
the
use
of
multiple
ports
for
P2P.
We
believe
that
this
may
be
a
way
to
solve,
for
helping
with
that
labeling
or
grouping
mechanism
for
internal
versus
external,
in
that
it
can
help
overcome.
C
Moving
on
from
there
we're
looking
to
just
introduce
more
constraints
around
how
we
can
manage
peer
bandwidth
consumption,
as
well
as
that
internal
versus
external
labeling
mechanism,
we'll
also
be
looking
into
whether
there's
any
sort
of
additional
tagging
outside
of
that.
That
may
set
us
up
for
additional
success
in
some
other
ways.
C
Only
other
things
I'll
mention
is
that
there's
just
a
couple
of
like
nickel
and
dimes
things
here
that
are
less
specific
to
the
overarching
theme,
but
are
just
some
material
issues
that
have
come
up
that
we
want
to
resolve.
So
we
had
discussed
briefly
on
this
call
needing
to
set
the
server
limit
for
this
specific
item,
since
it's
only
management
of
the
client
right
now
and
then
also
there's
just
a
recent
issue
that
came
up
related
to
P2P.
That
would
improve
quality
of
life.
C
To
simply
just
you
know,
stop
syncing
blocks,
while
snapshot
is
in
progress.
So
this
is
what
we've
outlined
thus
far
and
again,
once
we
learn
a
little
bit
more
from
your
feedback
on
4.0.3,
as
well
as
the
learnings
that
we
have
via
some
of
this
logging
around
peer
Health.
We'll
look
to
actually
do
some
more
work
from
here,
but
that's
where
we're
at
any
questions
about
what's
outlined
here
or
things
that
feel
or
missing
things.
You
guys
want
to
know
more
about
I.
I
Think
Michael
will,
like
the
multiple
peer-to-peer
course
thing,
because
that
way
you
can
have
your
internal
nodes
thinking
with
each
other
and
not
expose
that
to
the
public,
while
you're
in
catch-up
mode
right
and
then
the
peer-to-peer
external
one
once
ketchup
mode
is
off.
It
would
allow
incoming
connections.
I,
don't
know
if
that's
how
that's
described
but
I
think
that
would
fix
Michael's
situation.
E
H
I
G
Do
that
oh
well,
I
mean
I,
guess
I
have
the
impression
that
it
kind
of
gave
you
almost
like
a
trusted
or
untrusted.
So
one
node
can
have
a
trusted
peer-to-peer
that
your
internal
nodes
use
and
maybe
it
uses
and
and
doesn't
enforce
limits
and
whatever
rip
it
rip
it
rip
it
well,
whatever
you
want,
if
you
know
the
the
right
door
to
ask,
but
then
the
other
one
is
more,
you
know
what
in
bandwidth
limitations
or
connection
limits
or
sync
limits.
G
Kevin
yeah
yeah
I,
guess
that
was
intentional.
Why
does
that
I
guess
I
understood
that
was
my
intentional.
By
design
it
gives
one
node
the
ability
to
at
least
expose
a
private
board
that
you
can
use
if
you
know
it
or
this
default
peer-to-peer,
which
would
be
restrictable,
which
ties
into
all
the
rest
of
the
other
stuff
rapidly.
H
C
Some
of
the
tasks
that
have
been
broken
down
here
do
have
very
limited
or
missing
levels
of
definition
as
we're
working
to
break
that
down
further.
But
if
you
have
any
clarifying
questions
or
you
want
to
express
your
expectations,
feel
free
I'd
love
some
interactions
around
this
topic
and
thanks
everybody
thus
far
we'll
talk
soon,.