►
From YouTube: Leap EOS Node Operator Roundtable (Nov 16th) 2022
Description
This week the EOS Node Operator Roundtable updates the community on software upgrades and has a detailed discussion on how to make Net Plugin improvements and how best to move forward with introducing new topics and discussions to the community.
00:00:00 Start
00:00:03 Recap and this week's topics
00:01:09 Software development update
00:06:05 Net plugin improvements technical discussion
00:53:50 Wrapping it up with open questions
00:57:45 End
Summary
🟢 In progress action items are on track:
Antelope software/documentation updates on the way:
Leap 3.2 Final Release is expected within the next week.
areas to focus testing:
SHIP backports
HTTP 1.1 for API/cleos
Document on how crypto extensions inside CDT to utilize crypto primitive host functions
System contract updates
Release of DUNE in the next month
This week, we continued the technical discussion on P2P improvements, this time with a focus on Net plugin enhancements.
The outcome of this technical discussion is being tracked here:
Net plugin improvements eosnetworkfoundation/product#102
For next week, EOSUSA Michael has proposed a discussion on state database trimming.
Additional proposals are welcome! Leave a comment on this github issue and use the
reactions to upvote or downvote the proposals submitted.
Week 8 - November 16 - P2P improvements (Net Plugin Enhancements)
https://github.com/EOS-Nation/leap/issues/107
Participants (14)
Stephen Diesel
Kevin Heifner
EOSUSA Michael
Ross (EOSphere)
Matthew Darwin
brianhazzard
Daniel Keyes | EOS Nation
Corvin Meyer auf der Heide - cmadh | liquiid.io (Corvin Meyer auf der Heide)
Dario | EOSsupport.io
Max_Cho :: KOREOS Owner-South Korea
Jeff Werner
Bucky Kittinger
Ted Cahall
Randall Roland
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 #EOSIO #Web3
A
Amazing
all
right
welcome
everybody.
It's
November
the
16th.
It's
week,
seven
now
of
our
or
week,
eight
actually
of
our
since
EOS
Independence,
we've
sort
of
rebranded
this
from
our
EO
sleep,
upgrade
group
to
the
EOS
node
operator
round
table
and
we're
going
to
continue
down
that
path.
Last
week
we
discussed
sort
of
at
a
high
level
the
opportunity
for
peer-to-peer
improvements.
We
looked
at
the
new
RFP
that
was
posted,
and
the
goal
today
is
to
focus
more
on
the
net
plug-in
improvements
enhancements
improvements.
A
Whatever
you
want
to
call
it
before
we
get
into
that.
We
could.
Maybe
we
can
take
a
you
know,
quick,
look
as
we
normally
do
at
progress
towards
the
next
upgrade.
That's
still
going
to
be
part
of
the
Mandate
of
this
group
as
as
node
operators.
We
need
to
get
ready
for
the
next
upgrade
be
prepared,
know
what's
coming
share
feedback,
so
why
don't
we
start
there
Stephen?
If
you
can
give
an
update
on
on
how
we're
doing.
B
Yep,
it's
basically
the
same
update
this
go
around
with
the
exception
that
I
I
think
that
we're
feeling
comfortable
finalizing
the
release
of
3.2
for
leap
in
terms
of
the
timeline.
For
that
my
anticipation
is
that
it
will
probably
be
the
early
part
of
next
week,
there's
an
opportunity
that
we
over
deliver
and
get
it
out
the
door
before
the
end
of
this
week,
but
I
think
confidently.
B
A
B
So
I
I
I'd
say
that
we
we
feel
comfortable
moving
forward
with
the
release.
However,
I'm
never
gonna
say
no
to
more
Community
eyeballs
on
the
areas
of
focus
that
we've
asked
to
direct
attention
to.
So
you
know,
if
you
see
something
say
something,
but
so
far
the
the
the
testing
that
has
taken
place.
We've
resolved
all
of
the
issues
that
have
been
surfaced.
One
of
those
things
was
actually
related
to
ship.
That
was
in
a
previous
RC
already,
but
those
are
the
two
big
areas
of
change.
C
B
Last
week
we
discussed
that
last
week,
suddenly
there's
any
big
update
there,
but
we
just
kind
of
assumed
that
some
of
these
other
reposts
will
kind
of
prime
a
a
final
release
for
shortly
thereafter,
so
just
kind
of
following
along
in
steps.
Those
of
course
are
a
little
bit
less
critical
but
excited
to
make
progress
there
and
then,
just
as
we
kind
of
look
further
down
the
list
at
like
system,
contract
updates,
as
well
as
dune,
there's
still
a
little
bit
of
time
out.
But
you
know
that
they're
gonna
happen.
B
B
So
maybe
I'll
just
plant
a
a
quick
seed
here
and
it's
not
something
that
we
need
to
discuss
extensively
here
today.
But
one
thing
that
has
come
up
in
discussion
with
the
internal
team
is
just
kind
of
our
communication
strategy
around
for
releases
that
aren't
critical
in
the
form
of
requiring
a
consensus
upgrade
or
anything
like
that.
B
Those
are
just
some
things
that
we're
interested
in
some
input
on,
but
not
something
that
we
need
to
discuss
in
detail
today.
I
think
I
on
the
prize
for
today
should
be
the
discussion
of
the
net
plug-in
enhancements.
I
hope
that
that
request
is
clear,
though.
Obviously
this
3.2
release
has
some
really
awesome
stuff
in
it.
B
But
it's
not
something
that
we
need
to
like
drop
everything
and
make
sure
that
everybody's
great
at
the
same
time
right
so
just
how
we
start
talking
about
that
moving
forward,
especially
since
EOS
nation
of
course
leads
this
discussion
and
kind
of
supports
those
upgrades
to
something
that's
kind
of
been
fresh.
On
our
mind,
good.
A
B
Sure
so,
real
really,
where
we're
at
is
that
I
said
a
few
of
these
things
last
week,
but
I'll
try
and
say
it
a
little
bit
smarter
this
time
around.
You
know,
with
with
the
release
of
esio.
Historically,
there
were
some
complaints
about
the
performance
and
stability
of
net
plug-in.
There,
of
course,
been
some
enhancements
that
have
taken
place,
but
the
antelope
Coalition
has
selected
P2P
improvements
as
a
priority
in
both
of
the
prioritization
ceremonies
that
took
place
over
this
last
year.
B
B
What
what
that
really
entails,
for
the
most
part,
is
just
a
focus
around
the
the
process
by
which
a
node
may
be
able
to
manage
data
that
comes
in
something
that
Kevin
has
remarked
on
previous
calls
of
this
nature
is
just
that
when,
when
data
is
received,
that
isn't
the
exact
data
that's
needed,
it
will
go
round
robin
and
effectively
continue
to
look
for
the
exact
thing
needed
and
we're
throwing
away
data
unnecessarily.
So
there's
a
lot
of
waste
in
that
system.
B
You
know
if,
if
you're
constantly
disconnecting,
if
you're
getting
bad
data,
we
want
to
be
able
to
manage
those
peers
more
effectively
and
I.
Think
that
this
is
an
area
that
is
a
little
bit
more
ripe
for
discussion
with
this
group.
Outside
of
that,
there's
also
been
a
little
bit
of
discussion
around
like
what
additional
knobs
we
we
may
want
to
add.
B
You
know
we're
always
cautious
about
adding
more
abilities
to
tune
things,
since
it
invites
the
opportunity
to
break
things
but
just
being
able
to
set
like
specific
peer
count,
limits
or
bandwidth
usage
limits.
These
are
all
things
that,
just
you
know,
put
a
node
operator
in
a
place
of
Greater
control
over.
B
You
know
how
their
system
is
operating
and
how
they
interact
with
the
network
itself,
so
that
that's
really
what
we're
focused
on
and
then
one
thing
that
I
can
link
to
you
guys
is:
we've
talked
about
historically
net
plug-in
improvements
and
how
it
kind
of
goes
into
this
whole
spectrum
of
the
initiatives
that
we're
looking
to
tackle.
So
what
I'll
share
a
link
to
is
just
some
of
the
early
thoughts
around
Net
plug-in
improvements
directly
from
the
initiative
backlog.
B
Of
course,
this
brief
itself
isn't
fully
complete,
but
some
of
the
things
that
we
discussed
there
are
the
things
that
I
just
mentioned.
So
this
idea
of
a
block
buffer
that
allows
us
to
actually
manage
some
recent,
like
locus
of
State,
ahead
of
what
is
trying
to
be
captured
and
logged
so
that
we
can
actually
manage
this
data
better.
Some
of
those
knobs
that
we
mentioned
so
the
connection
count
and
bandwidth
usage
limit
and
then
actually
thereafter,
just
the
management
of
those
undesirable
peer
behaviors.
B
D
I
suppose,
just
just
to
State
the
obvious
to
a
lot
of
you,
the
net
plug-in
deals
specifically
with
the
the
peering
with
other
nodes
I
know,
because
I
just
want
to
just
make
sure
that
I
didn't
get
mixed
up
between
the
net
plug-in
and
another
plugin.
This
is
to
do
with
peer-to-peer
synchronization
and
everything
else
that
goes
with
it.
Right
just
wanted
to
state
that
in
the
call
that's.
B
D
Well,
we
actually
ended
off
the
last
beat
thing
with
me
saying:
Kevin
I'm
interested
with
some
of
the
things
that
you
had
already
picked
up
on,
and
maybe
we
could
just
discuss
a
little
bit.
I
know
Michael
you.
You
mentioned
one
of
the
challenges
we
had
where
it
doesn't
always
go
and
find
the
most
Optimum
Pier.
It
always
you
know
just
finds
whatever
pair
it's
got
and
the
peer
that
it
does
take
could
be
the
worst
and
then
we
spoke
about
maybe
some
kind
of
state
list.
D
E
E
However,
the
hell
I'm
able
to
do
that
things
like
that,
but
it's
more
yeah
related
to
some
of
the
actual
Logistics
and
intelligence
of
the
use,
because
it
was
always
kind
of
I.
Think
and
I
don't
know
every
line
of
the
code,
but
it
kinda
I'll
only
use
the
first
little
subset
and
I'll
kind
of
just
keep
working
my
way
through
them.
E
Your
problem,
if
they're,
not
you
know,
working
or
whatever-
and
you
know
that's
definitely
a
piece
on
a
more
Technical
and
even
protocol
level,
the
BPS
struggle,
because
we
have
our
own
level
of
peer-to-peer
meshing
requirements
and
even
completely
outside
of
just
the
normal
holistic
peer-to-peer
efficiency,
for
example,
idea
that
popped
into
my
head.
Don't
know
if
it's
doable
but
like
if
a
BP
could
advertise
its
private
address
that
it
wants
you
to
feed
directly
to
not
the
public.
E
Here,
the
private,
dedicated,
special
DPP
or
so
to
say
you
know,
I
mean,
would
there
be
benefit
in
the
logic
of
we
know
the
schedule?
We
know
who
our
neighbors,
why
key
a
BP
kick
into
a
make?
Sure
you
communicate
to
the
next
VPN
line.
They've
told
me
who
I
should
talk
to
where
I
should
talk
to,
as
it
changes
spook
shifted
over
to
here
and
have
it
much
more
intelligently,
streamlined
the
BP
handoff
process,
we've
we've
optimized
the
geographic
location,
for
whatever
reason
luck
has
it
EOS,
USA,
eosphere
and
EOS.
E
Rio
are
always
back
to
back
to
back.
So
we
always
cross
this
globe,
but
it
works
better.
Even
if
we
have
dedicated
peers
and
then
of
course
we
realign
geographically,
but
it's
tough,
because
you
appeared
to
this
person
and
then
all
of
a
sudden
Boom
the
schedule
changes
or
somebody
else
gets
rotated
in
or
even
these
not.
Everybody
is
at
the
technical
level
and
intimacy
with
our
networks
and
VPS.
B
D
E
D
D
G
Yeah,
the
the
the
BP
one
is
is
an
interesting
one
for
sure
I
mean
you
know,
one
of
the
problems
that
we
that
Stephen
is
has
in
his
document
there
I,
think
and
and
we've
talked
about-
is
that
you
know
the
net
plug-in
is
I,
don't
know
how
you
classify
it.
It's
optimistic
or
it's
in
a
sense
that
it's
it's
somewhat
stateless.
It
does
have
actually
state.
It
is
tracking
state
for
various
things,
just
not
things
that
are
important
for
the
conversation
that
we're
having.
G
But
so
yeah
I
mean
we've
talked
internally
the
fact
that,
like
maintaining
a
bit
of
State
and
using
that
state,
it
could
certainly
help
out
a
lot.
You
know
just
for
instance,
right
now,
just
at
a
very
high
level.
You
know
the
way
the
net
plugin
works
when
it's
syncing.
Is
it
just
round
Robins
around
the
the
list
of
peers
that
you've
configured
it
with
or
any
that
have
connected
to
it?
G
So
you
know,
unfortunately,
that
just
means
like
you
know
what
what
I
think
a
lot
of
people
do
in
the
public.
Is
they
just?
They
think
the
more
appears
the
better,
so
they
grab
the
biggest
list
of
beers
they
can
find
and
they
throw
it
into
the
config
thinking.
Well,
you
know
one's
good.
You
know,
100
is
better,
which
we
all
know
on.
This
call
I
think
that
the
opposite
of
that
is
actually
true.
G
So
what
the
net
plug-in
does
is
it
just
blindly
goes
through
that
list
and
says
well
I'll
sing
from
this
one
for
a
little
bit
and
then
I'll
go
to
the
next
one
and
then
I'll
go
to
the
next
one
and
if
it
during
that
process,
it
realizes
that
maybe
one
connection
doesn't
have
the
blocks
that
I
need.
Well,
it's
I
would
say
optimistic
in
the
fact
that
when
it
comes
back
around
it,
just
kind
of
assumes
well,
maybe
somehow
magically
that
that
node
now
has
the
blocks.
G
Have
the
previous
hundred
you
you
wanted
I,
don't
have
the
next
hundred,
you
won
either
and
I.
Don't
have
you
know
any
other
as
well,
so
a
little
bit
of
extra
communication
there
about
like
hey
by
the
way
here's
the
blocks
I
have,
and
so
you
know,
there's
no
need
to
ask
me
for
blocks.
I
don't
have
and
going
to
skip
over.
G
So
a
little
bit
of
like
enhancements
around
that
area
could
certainly
improve
the
whole
thinking
in
that
it
could
stop
asking
peers
for
data
that
it
that
it
knows
that
peer
doesn't
have
right.
Now
it
does
not
have
that
knowledge
and
it
doesn't.
It
doesn't
remember
that
knowledge.
It's
simply
blindly
tries
over
and
over
again
and.
C
G
I
was
kind
of
classify
here
is
a
stateless
sort
of
thing
of
like
just
well
I'll,
try
and
see-
and
you
know,
maybe
it
will.
Maybe
it
won't
and
then
you've
got
to
figure
that
out
each
time
and
that
that
takes
time
for
it
to
actually
figure
that
out.
So
there's
some
enhancements
there,
we've
talked
about
Stephen
talked
about
a
little
bit
of
buffering,
which
would
be
good.
You
know
right
now.
G
What
happens
is
if
you
get
if
you
get
Block
five
and
then
you
get
Block
well,
okay,
so
you
get
like
block
10,
but
you,
but
you
need
to
block
9
..
What
happens
is
the
10?
You
can't
use
so
you
throw
it
away
and
then,
when
you
get
nine,
you
use
it
and
then
you
realize
oh
where's
10
at
whatever
all
your
peers
have
thought.
They've
already
sent
you
10
and
so
you've
got
to
like
have
to
wait
and
figure
that
out
and
then
you
have
to
re.
G
You
have
to
request
for
10
and
you
have
to
wait
for
it
to
come
in.
It's
like
well,
okay,
that
works
quote
unquote,
but
obviously
it's
not
very
optimal
right.
If,
instead,
we
actually
saved
block
10
in
the
fact
that,
like
oh,
you
know,
I
need
nine
and
here's
10..
Well,
you
know,
there's
a
pretty
good
chance.
I
might
need
10
in
you
know
a
few
hundred
microseconds
here,
so
maybe
I
should
keep
it
around
and
not
throw
it
away
would
be
a
huge
enhancement.
It
doesn't
currently
do
that.
G
It
currently
says:
oh
I
got
10
I,
don't
I,
don't
need
it,
throw
it
away
and
then
and
then,
when
it,
you
know,
then,
a
little
bit
later,
it's
like
oh
I,
need
10..
Why
hasn't
anybody
sent
it
to
me?
Well
stupid?
They
did
you
threw
it
away,
you
know,
and
so
it
it
should.
You
know,
save
that
a
little
bit
so
those
you
know,
there's
some
enhancements
there
with
just
a
little
bit
of
maintaining
an
additional.
What
I
call
additional
state
that
could
get
can
help
it
out
in
a
lot
of
ways.
G
Now
you
know
one
of
the
things
that
we
talked
about
is
that
you
could
like,
if
you
configured
the
number
of
appears
that
you
want
to
remain
connected
to
so
the
idea
that
maybe
give
it
a
hundred
different
P2P
connections
or
peer
discoveries
feeding
it
with
a
bunch
of
connections.
Then
it
could.
It
could
determine
oh
of
these
100
I
found
through
communicating
with
them
that
this
top
can
figure
them
out.
G
F
G
Best
latency,
however,
under
that
scheme
it
doesn't
necessarily
address
the
BP
thing
that
was
just
discussed
right
and
the
fact
that
my
10
best
latencies
isn't
necessarily
and
probably
isn't
the
BP.
That's
before
me
right,
which
I
really
want
to
have
in
my
I,
really
want
him
to
be
connected
to
me,
because
when
it
comes
around
to
it
in
general,
he
may
not
be
the
best
latency,
but
for
that
particular
for
his
particular
block
range,
it's
very
likely
to
be
the
best
latency.
E
From
typically
it's
a
private,
it's
a
private
mesh,
you
know,
and
you
know
we
don't
really
want
to
expose
it,
then
we're
going
through
all
these
different
mechanisms,
but
the
thought
was.
Is
that
what
if
you
know
you
could
broadcast
it
and
it
only
accepted
like
yeah
I
mean
we've
got
the
key
locking
of
of
P2P.
You
know,
or
at
least
some
of
that
mechanic,
but
that
was
the
idea.
E
Is
that
cool
I
know
what
key
I
expect
you
to
use
to
have
this
super
secret
connection,
your
signing
key
and
therefore,
even
though
it
has
to
kind
of
be
exposed
it
could
you
know
it
won't
accept
connections,
because
it's
you
know
somewhat
self-secured
and
also
Dynamic,
but
anyway,
that's
why
I
say
it's
almost
two
layers
now
that
we've
kind
of
gotten
rid
of
the
top
layer
of
peer,
Discovery
or
isolated
it
not
gotten
rid
of,
but
then
the
next
thing
is
all
right.
Now
that
you
got
your
list,
how
efficient
is
it?
E
Can
we
have
some
State
and
be
a
little
more
intelligent
which
we're
making
progress
on,
but
then
even
more
so,
which
is
much
more
of
a
impacting
crippling
aspect
of
it
is
the
way
the
when
you,
you
load
those
blocks
up,
that
that
peering
of
inefficiency
is
amazingly
crushing
because
it
can
even
domino
effect.
You
get
two
or
three
of
them
in
a
row
and
it
you
know
it
really
kind
of
Cascades
and
then
guess
what
like,
like
Telos,
does
automatic
rotation
so
like
every
six
or
twelve
hours,
or
something
like
that?
E
You
know
I
mean
there's
potentially
another
shift
and
we
play
hell
last
block
Ford
last
block
Ford
last
block.
Forked
Nations
Mason
loses
a
lot
of
their
blocks
because
they
just
constantly
get
bounced
around
and
somebody
you
know
pessimistically
rejects
their
last
block
because
they
just
couldn't
get
it
through
the
public
hearing.
So
anyway,
I
I
thought
a
little
about
it.
I
couldn't
code
it
if
I
wanted
to,
but
yeah.
G
E
Would
be
well
the
BP
notes,
correct
and
like
I
say
not,
everybody
is
super
technical
as
awesome
as
we
would
want
them
to
be.
You
know,
depos,
a
lot
of
people
are
awesome,
meme
makers
and
software
developers
don't
know
or
care
about
that
BP
node
until
we
start
screaming
at
them.
Saying
dude
Sultan's
wrong.
I
can't
tell
you
I
can't
even
look
at
it,
because
I.
H
D
I
suppose
we've
got
three
things
then
right.
The
first
one
is
the
latency
and
the
pier
the
next
one
is
are
all
the
blocks
complete
in
the
pier
and
then
the
third
one
is
the
you
know
all
these
the
latest
blocks
from
the
BP.
That's
that's
producing.
You
know
that
kind
unappearing
like
are
we
updated
with
those
kind
of
blocks?
Well.
E
E
G
The
the
system
is
very
particular
about
you,
know,
hand
off
the
blocks
right.
We
know
this
right
and
fairly
recently
in
terms
of
like
you
know,
four
year,
five
years,
whatever
we've
been
running
this
thing
you
know
we
we
change
the
behavior
there
to
drop
last
block
right,
so
that
was
a
change
in
the
way
that
that
worked
in
terms
of
like
originally.
G
What
would
happen
is
if
you
got
a
block
late,
you
would
throw
the
block
away
that
you
were
currently
producing,
consume
that
block
and
then
restart
your
block,
and
so
what
that
did
was
late
blocks
kind
of
punished.
If
you
will
the
wrong
the
wrong
person
so
fairly
recently,
you
know
year
and
a
half
whatever
it
was
two
years
ago.
G
Maybe
now
it
probably
is
two
years
now
we
you
know
we
added
the
droplet
blocks,
which
means
that
if
I
don't
receive
the
block
from
the
previous
producer
and
it's
time
for
me
to
produce
the
block.
Well,
it's
their
fault.
They
didn't
get
it
to
me
in
time
and
I'm
going
to
start
producing
and
I
and
I
will
not
consume
those
blogs.
Now,
obviously,
other
people
in
the
network
will
and
so
either
way,
you're
going
to
get
Forks
it's
just
in
terms
of
like
who
wins.
E
To
produce
which
has
a
much
more
dramatic
effect
on
Layer,
Two,
Solutions
and
I
think
a
lot
of
people
take
into
account
because
you
know
they're
grinding
and
especially
from
the
ship
level.
I
mean
we're
just
ingesting
this
fire
hose
and
then
all
of
a
sudden.
It's
like!
Oh,
no,
all
that
work
that
you
did
and
all
those
commits
and
table
updates
in
your
database.
You
gotta
roll
them
back
and
catch
back
up
now.
So
you
know,
I
mean
you'll,
see
these
spikes
in
latency
of
of
and
the
dapps
go.
E
G
E
G
G
In
an
ideal
system,
you'd
want
it
where
you
know,
as
you
ramp
up
transactions
that
you
hit
some
level
and
that's
like
the
Max
and
then
like
it
just
wouldn't
go
any
faster.
But
that's
not
what
happens
right?
What
happens
is?
Is
you
push
it
up
once
you
once
you
pass
a
threshold,
your
performance
doesn't
stabilize
it
crashes,
so
you
go
from.
You
know
like
if
you're
Max,
let's
say
your
max,
is
whatever
10
000
transactions.
A
second
you
know,
maybe
you
can
prolong
at
that
forever.
G
But
if
you
try
15,
like
you,
don't
stabilize
at
11
or
10,
you
jump
down
to
five,
because
the
thing
just
just
Falls
all
over
itself
because
of
the
14
in
the
in
the
drop
blocks
and
everything
that's
happening
in
the
system
as
it
tries
to
like
you
know,
handle
this
load.
It
degrades
in
a
way
that,
and
so
that's
what
we're
trying
that's,
what
we're
trying
to
protect
against
right
and
so
again
that
goes
to
well.
G
You
know,
potentially,
if
we
can
figure
out
a
way
to
have
better
handoff
between
our
BPS,
then
we
can
get
to
a
system
where
we're
minimizing
these
Forks
we're
optimizing
our
handoffs
and
that's
something.
You
know
that
maybe
we
can
try
to
put
some
engineering
to
right
and
it's,
like
you,
said
it's
difficult,
because
you
know
what
what
do
you
want
to
do?
G
E
Say
it
was
you
obviously
I
identify
the
issue
right,
I
mean
and
and,
like
I
said,
say
it's
an
even
bigger
wide
reaching
issue
because
it
absolutely
crushes
everybody
everybody
forward
back.
You
know,
whereas
at
least,
if
you're
inefficient
at
your
peering
nodes,
you're
really
just
kind
of
crushing
you
and
your
peers,
but
like
say
I,
yeah
I
know
it
ain't
an
easy
fix.
I
know
it's
going
to
add,
you
know
latency
and
and
processing
and
stake,
and
all
of
that
but
yeah
I
mean
that's.
E
Why
at
least
I
don't
know
something
like
that
might
work
because
it
mimics
what
we're
basically
doing
now
you
know
and
and
still
has
the
ability
if
it
were
a
wire
guard,
private
mesh
or
if
it
were
a
public
peer
that
you
know
whatever,
but
just
the
nodes
to
know
of
each
other
and
the
BPS
to
try
to
more
efficiently
minimize
that
yeah.
It
is
a
feature
I
would
love
to
think
about.
I.
G
I
would
be
curious
to
hear
you
guys,
thoughts
on
trade-off
of
of
latency
for
performance
in
terms
of
like
you
know,
just
at
a
conceptual
level,
if
you
produced
all
12
of
your
blocks
in
a
round.
Let's
say
in
the
first
three
seconds
of
your
six
seconds
of
your
of
your
round,
then
that
would
potentially
give
much
longer
time
for
those
blocks
to
get
to
peers
and
get
processed
potentially
minimizing
the
number
of
forts
that
are
having
that
you're.
G
Having
so
I
think
like
we
could
optimize
performance
like
throughput
by
compressing
the
the
production
time
within
the
let's.
You
know
just
as
a
talking
point
the
first
three
seconds
of
the
of
your
six
seconds
right,
but
obviously
that
would
induce
latency
for
those
last
three
seconds
in
that.
If
someone
breaks
a
transaction.
E
I,
like
the
idea
you
had
presented
of
being
able
to
push
it
further
back
than
that
12th
block
right
because
I
mean
sometimes
it's
just
I.
Don't
know
you
can't
get
from
South
America,
it's
a
kangaroo
land
in
half
a
military
or
whatever,
but
yeah
I
mean
when
you
say
well,
you
know:
okay,
fine
I
know:
I
got
a
hot
rod.
E
D
E
Expiration
yeah,
it's
all
that
you
know
even
whenever
it
didn't
intentionally
happen,
some
of
those
expirations
started
triggering.
So
it
is
a
very
delicate
balance.
I
would
not
say
three
seconds.
You
know,
maybe
that
whole
last
second,
but
you
got
bigger
problems
if,
if
you
need
more
than
a
three
one,
second,
in.
G
Obviously,
if
you
even
just
waiting
for
one
block,
you
know,
presumably
if
you're,
if
you're
pushing
let's
say
in
the
first
few
seconds
there
you
know
you
don't
get
it.
Maybe
in
a
few
hundred
you
know,
on
average
you
get
it
on
250
milliseconds
right,
you
you've
been.
Let's
say
you
get
it.
It
gets
into
a
block,
you
get
it
in
the
next
block,
so
on
average
it
probably
well
less.
G
You
know
more
than
250
millise,
probably
on
average,
but
somewhere
around
that
right,
where,
obviously,
then,
if
you,
if
we
did
this
compressed
sort
of
timeline
where
we're
getting
we're
sacrificing
latency
for
throughput?
Well,
then
in
those
last
three
seconds,
if
you
push
right
at
that
boundary,
I
mean
it
could
be
three
and
a
half
right
seconds
before
you
get
an
indication
that
it's
in
the
first
block,
so
yeah
you're.
G
G
G
H
E
G
I
mean
there's
other
things
we
could
do
right,
I
mean.
If
there's
you
can
go
the
opposite
direction
as
well
like
we
could
do
200
millisecond
block
time
for
100
millisecond
block
times
right
and
get
you
even
smaller.
Ladies
I
mean
that's
all
dual,
but
you
know
we
have
issues
sometimes
with
500
or
yeah
500
millisecond
block
times
you
crank
it
down
to
100
millisecond
block
times,
and
you
know
yeah.
E
I
mean
even
just
some
transactions
we're
finding
are
bigger
than
100
milliseconds.
You
know,
I
mean,
and
so
anyway,
I
I
yeah
I'm,
not
the
biggest
fan
of
it.
You
know
trying
to
dynamically,
do
it
as
fast
as
they
can
and
just
shove
it
down
the
pipe
so
to
say,
because
I
do
feel
like
that
would
transpose
as
as
ux
Badness,
but
I
know,
you
had
talked
about
having
the
ability
to
to
back
more
than
just
that
last
block,
either
11th
or
tenth.
E
E
I
All
right
so,
since
you
asked
I,
guess
the
you
know,
Kevin
and
I
discussed
this
idea
of
you
know:
Shifting
The,
Block
production
like
two
years
ago
when
we
were
having
all
the
problems
on
the
yes
I
mean
that
and
so
I
think
it's
a
worthwhile
discussion,
because
you
know
we
can
get
more
transactions
per
second.
If
we
can
get
bigger
blocks
and
if
we
get
bigger
blocks,
then
we
need
more
offset
time
between
the
block
producers.
I
So
for
me
it
sounds
like
more
like
a
consensus
protocol
upgrade,
it's
called,
you
know,
block
offset
milliseconds
or
something
so
you
you
know
you
take
Point,
whatever
small
amount
of
milliseconds
off
each
block,
so
each
block
sits
slightly
before,
and
that
leaves
a
bigger
Gap
at
that
right,
so
not
like
a
whole
second,
but
maybe
an
extra
half
a
second
and
the
next
half.
A
second
is
probably
not
that
noticeable
from
a
ux
perspective,
but
it
allows
a
much
bigger
block
time.
I
So
maybe
thinking
about
it
on
that
level,
rather
than
like
an
extreme
three
seconds
that
might
help
the
other
thing.
That
is
a
problem
today
is
when
the
the
network
gets
overloaded
with
tons
of
transactions
and
especially
like
spam
transactions
or
failed
transactions,
then
that
impacts
the
block
propagation.
I
So
the
the
solution
that
we
came
up
with
two
years
ago,
which
most
people
have
not
actually
implemented,
which
is
set
up
a
dedicated
peer-to-peer
node
that
only
exchanges
blocks
and
then
don't
you
know,
don't
send
the
transactions
through
and
then
that
reduces
the
load
by
a
lot.
So
can
we
make
that
auto
negotiation
easier
or
whatever,
so
that
people
don't
have
to
think
about
how
to
set
that
up,
because
doing
that
all
manually
or
running
a
separate
node,
it's
too
complicated,
too
expensive
and
I?
I
Don't
know
most
people
don't
bother
and
then
it
doesn't
work
and
then
we
still
get
all
the
forks.
So
how
can
we
be
intelligent
that,
if
you're
connected
to
your
next
BP
in
the
peering,
coming
back
to
Michael's
idea
of
like
understanding
the
BP
schedule,
well
only
send
the
blocks
right?
So
you
know
how
can
we,
you
know,
make
some
more
intelligence
on
the
transactions
versus
blocks
and
what
we
send
between
peers.
E
I
E
G
I
mean
I
do
think
like
if
we
did
do
something
with
a
BP
Network,
where
the
the
note
understood,
BP
connections,
different
than
other
connections,
then
yeah
we'd
add
that
I
think.
Definitely
we
would
add
to
that
that
it
should
just
be
block
only,
and
that
would
be
a
simple
ad
on
the
other
right
that
that's
not
a
that's,
not
a
large
list,
because
we
already
support
that
capability.
It'd
just
be
like
okay.
E
The
ones
I
they
worked
and
that's
what
I
had
pared
down
to
in
my
scrambling
and
troubleshooting
and
I
get
what
was
going
on
and
that's
when
I
was
like
holy.
We
got
to
do
something
guys
because
it
fixed
it,
but
as
I'm
going
to
these
other
chains,
we're
looking
at
other
chains
that
are
experiencing
this
right
now.
Is
that
hey
guys
I
need
you
to
throw
five
nodes
at
it
and
set
up
all
these
dedicated
check
out
the
Nations
article
and
Sweden's
article,
and
then
Ross
has
a
little
bit
peppered
in
his
and
they're.
G
E
I
Yeah,
but
you
know,
I
can't
have
one
node
who's
listening
on
two
different
parts
for
one:
only
except
transactions
here
and
only
except
blocks
here
or
except
blocks,
and
transactions.
I
want
and
I
only
said
block
on
the
other.
One
right
I
have
to
set
up
a
dedicated
peer
to
make
sure
that
I
only
get
Block
connections.
G
F
I
G
And
that's
actually
there
today
that
the
net
plug-in
is
multi-threaded
and
it
pro
it
processes
on
a
single
thread.
Transaction
is
actually
a
low
priority
and
block
to
high
priority
and
the
way
that
works
is
there's
a
priority
queue,
and
so,
when
a
block
comes
in
and
gets
digested
by
a
thread
and
an
up
plug-in,
it
gets,
it
gets
queued
up
on
the
main
thread
now.
Obviously,
that
main
thread
has
to
has
to
you
know
finish
what
it's
currently
doing,
but
the
very
next
thing
it'll
pick
up
is
is
a
block.
E
Yeah,
yes,
I'll
piggyback
on
that
is
that
I've
noticed
my
public
peer-to-peers
are
getting
I'll,
say
a
b,
it's
not
normal,
but
they
are
just
getting
smashed
to
the
point.
I
can't
reboot
the
mode
it
never
I
mean
I
can
sit
Kelly,
you
know,
I
mean
and
then
corrupt
it
and
launch
it
and
fix
it,
but
it
seems
to
be
peer-to-peer
they're
very
effectively,
able
to
kind
of
lock
it
up
and
even
kind
of
chew
up
some
slots
and
or
I
can't
kill
even
node
OS
gracefully
because
it
has
some
kind
of.
E
H
E
E
I
I
don't
have
this
problem,
but
and
I've
I've
showed
you
all
of
that.
Something
about
my
I
mean
I'll,
see
ratcheting
people
just
keep,
adding
dozens
and
dozens
and
dozens
and
dozens
of
peers
and
I'm,
like
that's,
not
obviously
natural
traffic,
but
and
it's
not
all
my
peers.
So
it's
not
my
h8
track
proxy
timeouts
or
anything
like
that.
But
it's
only
the
public
peer-to-peer
nodes
that
really
I
I
can't
stop
and
start
them
with
the
simple
the
whatever.
E
Yeah
he
loves
coming
into
my
world.
I
mean
I've,
never
had
a
developer
Bill
holy.
You
really
are
the
best
at
breaking
things
so
anyway,
but
it
it
obvi.
We
have
a
lot
of
protections
from
the
agency
key
level,
but
very
very
little
I
mean
I,
can't
even
see
what
the
hell
they're
doing
other
than
if
it
normally
has
36
public
peer-to-peers,
when
it
just
sequentially,
goes
up
to
120
and
then
boom
falls
off.
E
Hi
Alex
somebody
ain't
doing
something
right,
I,
don't
know
what
it
is,
but
that
in
tandem
with
that
node
is
not
liking.
It
so
something
else
to
speckle
into
that
that
whatever,
but
by
far
by
far
my
opinion
would
be
this
BP
peering
and
some
intelligence
will
help
all
the
chains
remain
a
little
more
stable
and
even
the
yeah
okay
slice
a
little
bit
off
of
each
block
time.
E
I,
even
like
the
idea
of
that
block
time
being
chain-wide,
because
I
have
spent
years
training
people
you
have
to
offset
your
life
block.
You
have
to
offset
your
last
block.
You
have
to
offset
your
last
block.
They
don't
do
it.
They
Fork
out
it'd,
be
awesome.
If
the
chain
could
just
say
look
guys,
we
all
agree,
everybody
needs
300
milliseconds,
because
it's
the
interwebs,
you
know
to
have
that
kind
of
enforced
in
the
nodes
just
be
like
you're
right,
I,
don't
have
to
be
told
to
have
a
default.
I
could
be
overridden
right.
E
Oh
you've
got
a
10,
Canon
strings
cool,
South
America.
You
need
a
little
bit
more
time
override
it,
but
at
least
at
the
chain
level
to
say
in
whatever
way,
Matthew
was
the
trimming
of
the
individual
blocks
throughout
the
round
in
relation
to
just
how
bad
node
OS
snowballs,
when
you've
got
the
fire
hose
of
spam
transactions,
it's
just
smashing
200
milliseconds
and
200
milliseconds,
and
it's
just
not
really
enough,
whereas
if
you
would
just
slow
down
a
little
bit,
it
wouldn't
yeah.
I
I
I,
it's
hard
to
remember
exactly
what
Kevin
and
I
were
talking
about
years
back,
but
it
was
in
the
context
of
if
the
block
is
already
full
and
I
have
a
pile
of
transactions
already
queued
up
here.
Why
am
I
sitting
around
waiting
doing
useless
stuff
when
I
can
start
creating
the
next
block
and
fill
up
with
the
transactions?
I
already
have.
E
I
So
on
the
in
the
theory
is:
if
the
blocks
are
small,
then
the
normal
schedule
applies
because
well,
there's
enough
like,
if
you
produce
a
small
block,
that's
at
the
very
end.
You
have
enough
time
to
get
it
to
the
next
person.
If
you
produce
a
very
big
block
at
the
end,
you
don't
have
enough
time,
but
if
you
have
a
very
big
block
at
the
end,
probably
all
the
other
blocks
in
the
chamber
big
too.
E
I
Because
and
then
this
actually
increases
the
TPS,
because
now
like
currently,
our
last
block
is
like
always
like
tiny,
because
we
need
to
make
it
really
small
because
we
need
to
get
it
there.
So
let's
make
the
left
block
a
little
bit
bigger,
but
it
will
just
be
a
little
bit
earlier
right
so
anyway
that
that
you.
I
E
I
Like
the
idea,
but
what
you
know
from
my
perspective,
I'm
trying
to
measure
the
BPS
are
doing
well.
So
if
there's
this
Dynamic
schedule,
that
makes
it
really
hard
to
tell
if
somebody's
doing
the
wrong
thing
right.
So,
if
there's
a
fixed
schedule,
then
the
the
monitoring
systems
can
then
tell
if
the
people
are
on
time.
E
I
E
I
So
I
mean
on
EOS;
traditionally
we
didn't
have
the
Rio
and
Australia
or
you
know,
so
it
was
all
you
know:
North
America,
Europe
Asia,
so
it
was
all
in
the
northern
hemisphere.
So
we
didn't
have
these
big
fork
problems
right
like
at
one
point
us
nation
was
between
I
forget
who
somebody
in
Japan
and
somebody
in
Europe.
So
we
had
the
blocks
coming
in
and
the
blocks
like.
So
it
was
the
worst
possible
case.
We
were
right
in
the
middle
of
that
and
it
worked
so
we
managed.
E
E
Or
change
the
rotation?
That's
really
you
know,
I
mean
it's
it's
more
dynamic
in
some
chains
than
others,
but
I
mean
obviously
it's
it's
very
fluid
and
designed
to
be
like
that,
and
it's
had
I
think
all
of
us
probably
have
gotten
burned
on
one
of
the
chains
or
another
by
the
damn
I'd.
Do
it
the
right
way
and
I
still
am
struggling.
A
A
Sounds
like
Steven's
got
some
promising
new
features
to
add
to
the
backlog
here.
How?
How
do
you
guys
want
to
move
forward?
Do
we
do
we
want
to
for
next
week
continue
on
this
topic?
Is
there
a
new
topic?
Are
there
some
further
questions?
We
want
to
dig
deeper
into
I
noticed
you
had
some
open
questions
in
the
issue
you
shared
there
Stephen.
A
If
we,
if
we
do
introduce
net
plug-in
block
buffer,
where
in
the
architecture
should
I
live,
if
we
are
to
design
a
period
node
ratings,
what
additional
data
would
we
like
to
capture
to
establish
a
baseline
rating
for
peer,
ranking
and
management,
and
what
about
IPv6
compatibility
I'm,
not
sure
if
those
are
questions
suited
for
this
group
or
another
group,
but
I
notice?
You
have
those
here
in
the
in
the
issue
you
shared
so
I,
guess:
I'll
pass
it
to
you
Steve
any
thoughts
on
on.
B
So
I
think
what
I'd
like
to
do
is
I'll
have
an
opportunity
to
kind
of
circle
back
through
this
recording.
Once
more.
Just
to
polish
up
my
notes,
I
I,
don't
think
that
it's
critical
that
we
continue
the
conversation
specifically
on
this
topic,
unless
you
guys
feel
like
you'd
like
to
continue
the
conversation.
We've
got
a
lot
of
good
ideas
out
here
today.
All
of
that
should
be
incorporated
into
that
initiative
issue
that
I
had
linked
previously
in
the
call
and
like
that'll
kind
of
be
our
pattern.
B
So
if
you
look
at
those
pending
PRS-
and
there
are
specific
things
related
to
node
operators-
that
you
guys
want
to
bring
here
and
discuss,
I
think
that
that's
a
really
great
Avenue,
and
also
that
means
that
you
can
submit
PRS
right,
like
you-
can
submit
a
PR
as
a
product
proposal
related
to
node
operator
needs,
and
we
can
Lobby
to
have
that.
Be
the
next
round
table
discussion
that
takes
place
here.
B
E
B
Totally
yeah
and
also
helping
Brian
hit
the
ground
running
since
he's
gonna,
be
increasingly
more
engaged
on
this
front,
really
excited
to
have
the
team
growing
and
to
have
these
conversations
flowing
as
well.
You
have
to
excuse
my
mayor,
so
I
gotta
hop
for
another
meeting,
but
you
guys
have
a
great
day.