►
Description
The Leap working group briefly goes over software development and has an in depth technical discussion on the blocks.log survey, how best to move forward based on the feedback results and the importance of transparency.
00:00:03 Start
00:00:13 Recap and this weeks topics
00:01:46 Software development updates
00:05:31 Blocks.log survey discussion
01:15:00 End
🟢 In progress action items are on track:
Antelope software updates on the way:
Leap 3.1.3 patch release
Leap 3.2.0 RC2
CDT 3.1.0 RC1
System contract updates
Release of DUNE in the next month
We hosted a deep technical discussion among some of the highly technical EOS BPs, ENF and OCI on the topic of the survey seeking feedback on the usage of blocks.log files.
Voices on the call were aligned with the results of the survey with a
few exceptions.
In general:
There is a need for a chunked blocks.log file, but the way it was
implemented in EOSIO v2.1 was no useful because the
archived blocks aren't easily accessible.
There is value in having the ability to store some blocks in
different locations, such as in slower disk storage.
BPs would appreciate another way to share blocks between
nodeos instances (in particular, similarly to how Ethereum
supports automatic peer discovery and automatically
downloads and backfills the history over BitTorrent.)
For nodes that serve API queries, BPs would appreciate a way
for nodeos instances with partial blocks to retrieve blocks from
another nodeos instance to fill API requests for blocks it does
not have locally.
As a result of the technical discussion, a few new features were
added to the ENF's development backlog.
Next week, the ENF will be providing a demo of their public program
management system to provide more transparency into the Antelope
development roadmap and give the community an opportunity to
influence it.
Participants (11)
Max_Cho :: KOREOS Owner-South Korea
Kevin Heifner
Daniel Keyes | EOS Nation
EOSUSA Michael
Jeff Werner
Denis Carriere
Matthew Darwin
Stephen Diesel
Max_Cho :: KOREOS Owner-South Korea
Randall Roland
Ted Cahall
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 #ENF
A
All
right
welcome
everybody.
It
is
what's
the
day
today
it
is
October
26th.
This
is
our
fifth
week
since
EOS
Independence
Day
on
the
agenda.
Today,
we've
got
a
kind
of
sort
of
a
special
edition
of
the
leap
upgrade
call
today.
Last
week,
we
we
shared
some
of
the
results
of
the
survey.
That's
been
going
around
that
EOS
support
has
been
helping
to
distribute
and
track,
and
this
is
a
requesting
some
feedback
on
the
blocks.log
files
in
it.
So
yeah,
like
I,
said
we
checked
in
on
that
we
have.
A
Last
week
we
had
nine
responses,
not
sure
if
we
have
much
more,
but
we
can
have
a
look,
but
we
decided
it
would
be
valuable.
Besides,
just
looking
at
the
survey
actually
having
some
of
the
technical
folks
that
use
this
stuff
on
a
call,
have
a
chat,
talk
through
our
use
cases
and
our
needs
and
see
if
we
can
get
a
little
deeper
insight
into
into
what
we
need
here.
A
On
top
of
that,
we've
got
we
checked
in
on
the
progress
with
the
elite
development
rc2,
with
some
bug
fixes
with
it
was
expected
by
the
end
of
the
week.
So
we
can
check
in
on
how
that's
going
CDT
release
3.1
also
was
expected
by
the
end
of
the
week
or
end
of
the
week
or
early
this
week,
and
system
contracts
and
reference
contracts
are
also
being
worked
on
to
make
a
little
more
user-friendly,
in
particular,
with
the
some
differences
between
the
different
chains.
A
B
B
B
I
think
that
we've
had
some
success.
Getting
that
fix
in
related
to
that
M
Sig
time
lock,
issue
we're
just
working
on
cleaning
all
that
up,
I
think
it's
going
to
be
integrated
into
the
reference
contracts
sooner
than
later,
if
it
hasn't
already
haven't,
checked
and
then,
of
course,
we'll
incorporate
that
into
eosystem
contracts.
We
also
anticipate,
probably
within
the
next
month
or
so
well,
I'd
say
within
the
next
month:
a
release
of
Dune
as
well.
B
A
B
Yeah
3.1.3
3.2.0
and
that
CDT
release
should
happen
consecutively
as
they're
ordered.
Okay,
like
it
should
be
pretty
quick.
You
know
the
patch
release
we
just
need
to
get
out
before
that
rc2
and
then
CDT
I
think
we're
on
track
to
release
this
week.
The
only
thing
that
might
be
missing
from
these
notes
is
just
an
in
anticipated
EO
system
contracts
released
between
the
CDT
release
and
the
Dune
release
foreign.
A
All
right,
in
that
case,
let's
move
along,
so
the
feedback
survey
was
shared
with
block
producers,
although
I
don't
believe
we
got
a
whole
lot
of
responses.
Let
me
see
here:
do
we
have
anything
new?
Is
this
random?
We
got
Randall
on
the
line
here
right
is
this?
The
latest
results
are
all
included
in
here.
Is
there
anything
new
since
we
checked
in
last
week,
no.
A
In
the
last
week,
cool,
that's
fine,
I,
think
I
think
we
were
expecting
relatively
low
response
rate
to
this
one.
It's
pretty
technical
question
and
again
we
got
some
of
the
experts
in
the
industry
on
the
call
right.
Here
we
got
Michael,
we
got
Matthew,
we
got
I,
don't
know
if
Denny
is
able
to
contribute
in
this
topic,
probably
not
as
much
as
Matthew.
A
Maybe
we'll
see
Ross
join
in
at
some
point,
but
in
anyways
we
can
get
started.
How
do
we
want
to
handle
this?
We
want
to
start
by
maybe
going
over
the
results
that
we
have.
Maybe
we
can
use
that
as
a
jumping
off
point
comment
on
what
we
see
here,
add
our
two
cents
as
we
go
and
and
anything
else
that's
not
been
captured
in
a
survey
we
can.
We
can
discuss
as
well.
A
So
the
very
high
level
results
we
had.
Nine
respondents.
Is
there
a
need
for
chunk?
Blocks.Log
six
people
said
no.
Four
people
said
yes
and
when
once
we
look
through
after
we
blew
through
the
very
high
level,
we
can
actually
look
at
the
individual
responses
blocks.log
in
different
locations.
We
had
six
yeses.
Two
no's
one
other.
A
A
C
I
almost
feel
the
survey
is
not
particularly
relevant
because
it
wasn't
exactly
focused
only
to
block
producers,
so
there's
people
in
the
survey
that
came
back
that
possibly
are
developers
or
possibly
are
you
know,
or
even
just
you
know,
not
related
to
running
a
block
producer
node,
so
they
they're
answering
honestly
but
they're,
not
the
target
audience,
and
that
was
the
right
we
couldn't
validate,
which
block
producer.
Each
of
these
responses
came
back
from
so
I
I
think
we
should
take
some
of
these
answers
with
a
grain
of
salt
and
realize
that's.
C
Why
we're
doing
this
call
today
is
that
we
want
to
ask
people
like
Michael
like
Matthew
like
Ross,
you
know
like
hey.
What
would
you
do
with
this?
Do
you
do
you
want
this
Etc
and
that's
where
we're
trying
to
look
for
a
way
to
make
more
targeted
surveys
where
we're
only
surveying
and
we're
looking
and
we
and
we
have
the
exact?
Who
was
the
response
that
this
came
from
this
block
producer?
C
D
You
know
the
they
run
it
and
obviously
they
don't
you
know,
do
a
lot
of
heavy
lifting
off
of
it.
They
do
whatever
they
need
to
do
off
of
it.
So
versus
some
of
us
that
just
get
smashed
with
millions
of
transactions
and
run
dozens
of
nodes
and
different
change
or
at
different
levels.
So
yeah,
you
know,
we've
all
had
some
different
experiences.
Yes,.
A
A
Yeah
cool
so
we'll
we'll
learn
for
the
next
one,
and
maybe
we
can
just
kick
off
the
discussion,
then.
How
do
we
want
to
do
this?
Do
we
have?
Is
there
like
a
so
I?
Have
the
question
here?
Is
there
a
need
for
maybe
we
could
start
with
the
questions
here
and
just
get
feedback
from
the
people
on
the
line
and
we'll
maybe
go
go
around?
Who
wants
to
start
off?
A
D
Well,
they
figured
it
out
I
guess
we
can
get
started
I.
My
my
opinion
is,
is
yes,
it's
helpful
to
be
able
to
split
up
the
big
files
because
it
just
keeps
growing
and
growing
and
growing
and
growing,
and
you
can
keep
throwing
you
know
slower,
spinning
rust
at
it.
But
you
know:
I
mean
I.
Think
I've
got
a
two
terabyte
block
log
file
on
one
chain,
just
a
block
log,
not
State
his
but
and
I
assume.
This
discussion
is
focused
more
around
just
the
block
logs.
D
There's
also
some
more
mechanics
related
to.
Why
do
you
need
a
full
block
log
you
know
and
and
we
get
by
on
truncated
logs,
but
obviously
I
can't
answer
an
old
request
because
I'm
running
it
on
a
one
terabyte
drive,
you
know
an
nbme
drive
and
damn
I
mean
do
I
need
to
throw
a
16
terabyte
in
there
or
whatever
to
go
with
just
a
service
of
public
API.
That's
getting
smashed
into
Oblivion,
or
even
some
I,
don't
know
idealistic
concepts
of
well.
Why
do
you
need
the
full
block
log
on
all
nodes?
D
What
if
it
had
kind
of
the
gray
Mass
mentality
of
layering?
Let
me
put
some
apis
up
front
that
are
lights
and
get
smashed
on,
but
don't
have
a
big
log.
Don't
need
a
big
log,
but
not
have
to
build
some
Frankenstein
in
Jinx
failover
type
of
system
to
where,
when
I
reboot,
my
public
API
nodes
that
have
this
two
terabyte
block
log
file,
I
cringe
because
half
the
time
they
won't
even
stop
the
p2ps.
Have
them
locked
up.
The
API
calls
just
don't
stop.
D
You
know
I
mean
it's
a
pitch
to
run
a
public
API
mode
and
take
you
know
that
abuse
and
then
all
right
I
need
to
reboot
it
just
to
update
it.
It's
gonna
crash
I'm
gonna
have
to
kill
it,
which
is
gonna
corrupt.
The
block
log
file,
which
means
then
I,
can
use
my
snapshots
and
roll
it
back
and
spend
the
next
hour
doing
that
and
hope
to
God
it
didn't
clip
lock
logs
in
a
bad
location,
Kevin
can
probably
attest
I.
D
E
C
Go
ahead:
do
you
have
a
desire
to
sweep
older
parts
of
the
log
out
to
like
S2,
buckets
or
stuff
like
that
that
later
you
might
still
want
to
go
back
and
look
at
them,
but
you
you
want
to
keep
the
Old
Log
parts
for
a
while,
because
the
splitting
makes
it
where
you're
sweeping
older
Parts
out
to
slower
less
expensive
storage,
but
still
maintaining
a
more
current
locus
of
the
log
that
you
know
it.
You
know,
but
so
you've
got
a
decent
sized
log
file,
but
you
you've
got
the
whole
history
somewhere
else.
C
D
D
Correct
correct:
that's
what
I
say
for
the
sake
of
the
argument:
any
sort
of
sloughing
it
splitting
it
off
and
and
I
also
have
to
be
honest.
I
haven't
had
a
great
opportunity
to
break
a
lot
of
a
log
split
machine
right,
so
I
mean
I
haven't
had
to
unjam
a
split
machine
I,
just
don't
Jam
nvme
drives
all
the
time,
but
yeah
I
mean
what
I
you
know.
It's
not
so
much.
Yes,
the
sweeping
feature
and
offloading
it
to
a
you
know.
Spinning
rust,
Drive
I
mean
a
couple
hundred
dollars.
D
D
That
said,
this
node
doesn't
have
it,
but
don't
40,
for
it
relay
it
through
to
the
next
server
and
kind
of
work.
Your
way
down
the
line,
you
know
what
I
mean
and
it
allowed
you
to
better
run
a
split
note
up
in
front.
Let
it
get
destroyed,
launch
it
from
a
snapshot
every
single
time,
whatever
you
got
to
do
right,
but
in
order
for
that
consistency,
do
you
really
need
I?
D
You
know
I
mean
the
delicacy
of
those
block
logs
and
being
split
or
even
be
able
to
be
shared
I'm,
not
a
big
fan
of
sharing
them,
because
I've
jacked
things
up
so
bad
from
one
node
I
Hyperion
I've
taken
out
nine
servers
at
one
time
because
one
went
rogue,
they
won't
ever
talk
to
each
other
again,
so
they're
all
Independents,
you
know,
so
that's
just
how
we
live.
We
just
throw
Hardware
at
it,
but
I'll
stop
I.
Think
Matthew
gut
is
thank
you.
F
F
F
C
F
D
Do
you
do
that
and
I'd
say
from
the
Bulldogs?
The
peer-to-peer
is
probably
more
critical
that
I
see
because,
yes,
very
few
people
ask
for
old
blocks
a
lot
of
people
decide.
They
want
to
go
down
the
path
of
sinking
the
full
chain
and
nobody's
peer-to-peer.
Well
I
mean
some
others
do.
But
you
know
I
mean,
and
the
peer-to-peer
mechanism
is
a
lot
more
difficult
to
transition,
but.
F
Yeah,
you
I,
don't
know
how
to
parse
the
protocol
to
build
a
proxy
to,
but
it's
possible.
But
you
know
it's
I
can't
just
configure
the
load
balancer
to
do
that.
It
has
no
concept
of
the
computer
program,
foreign.
So
to
me,
I
think
the
you
know
better
solution
is
to
work
more
on
the
layering
and
make
that
an
easy
way
to
figure.
Oh
I've
got
part
of
it
here,
but
go
look
over
there
for
the
rest.
D
Correct
but
as
maybe
phase
one
that
feature
you
were
talking
about
is
I
mean
if
you're
gonna
sweep
them,
don't
forget
about
them
and
that
at
least
helps
we
can
throw
I
was
just
looking
at
8
and
16
terabyte.
You
know,
spinning
rust
drives
I
mean
you
know
a
couple
hundred
dollars
at
least
I
can
throw
20
terabytes.
You
know,
I
had
it
so,
but
it
needs
to
be
able
to
yeah.
Hey,
oh
you're,
asking
for
Block
ten
thousand.
Oh
all
right,
I
got
it,
but
I'm
gonna
have
to
go
to
the
back.
A
E
F
F
C
This
this
would
be
making
the
concept
of
2.1
usable
for
the
block
producers,
because
now
the
split
off
pieces,
even
though
they
might
be
on
a
different
disk
somewhere,
are
still
accessible
on
slower
disk
and
just
some
type
of
a
meta
directory
feature.
That
says
this
is
where
my
sweep
directory
is
and
that's
where
you
go.
Look
when
we've
split
the
file
and
we
make
the
feature
we
bring
back
the
concept
of
the
feature,
but
we
make
it
far
more
usable
for
the
block
producers
that
want
it
right
exactly.
F
C
You
can
you
share
why
you
might
want
more
than
one
slower
or
secondary
directory
like
to
me,
and
my
the
concept
to
me
would
be
here's
the
directory,
where
the
main
block
log
is
here's
where
the
sweep
directory
is,
and
you
pick
one
obviously
there's
inode
issues
and
all
kinds
of
stuff
like
that
at
some
point
is,
are
you
thinking
like?
Oh,
my
god,
there
could
be
thousands
and
thousands
of
files
and
you
overload
the
inodes
or
something
or
if
it's
a
single
directory.
What
was
your
thinking
behind?
Why
you
bought
more
than
one.
D
C
G
C
I
know:
are
you
saying
for
another
block
producer
to
be
able
to
pull
chunks
from
other
block
producers,
or
are
you
saying
yeah
for
the
sweep
of
okay?
That's
part
of
the
P2P
rewrite
that
we're
working
on
and
we're
calling
that
the
Swarm
download
feature.
That's
a
feature
that
we've
postponed
out
of
the
current
P2P
read:
write.
First,
we're
doing
a
network
optimization,
you
know
for
host
Discovery
and
the
follow-on
phase
would
be
exactly
this
swarm
download
that
you're
describing
which
would
likely
use
this
feature.
C
If
block
log
splitting
was
uniform
across
all
block
producers
so
that
all
block
producers
have
the
same
split
logs
so
that
the
chunks
were
all
of
the
same
size
and
at
the
same
block,
Heights
Etc,
so
that
the
Swarms
could
come
it
would.
It
would
truly
be
BitTorrent
and
that's
a
design
goal
and
what
happened
was
the
Coalition
voted
when
and
oci
came
back
with
this
proposal
that
it
was
take?
C
It
was
too
long
like
the
The
Proposal
was
going
to
be
including
the
support
it
was
about
a
year,
so
it
was
a
nine
month
proposal
and
the
expense
was
too
high
for
the
current
amount.
The
month
the
Coalition
was
willing
to
spend
so
right
now
it's
been
broken
into
two
and
the
first
one
will
then
re
be
rebid,
which
is
network
discovery,
and
once
that,
like
Discovery,
is
completed,
a
second
RFP
will
go
out
which
will
be
for
the
Swarm
download.
F
C
A
Yeah,
that's
the
way
they
do
it
on
ethereum,
right,
Matthew,
I,
know,
I,
know
you
I've
you've
shared
your
your
experience
as
a
node
operator
playing
with
setting
up
your
your
first
ethereum
nodes
versus
on
ethereum.
It
sounds
like
there's
quite
a
difference
in
that
ability
to
spin
up
a
node
and
just
download
everything
automatically
quickly.
In
the
background,
yeah.
F
F
A
D
Or
is
that
really
I
mean
you
can
make
peer-to-peer
and
I
know?
Let's
say
that's
a
a
separate
agenda
item
or
whatever,
but
it
does
kind
of
roll
into
it.
You
know
I
mean
it's
the
efficiency
of
the
peer-to-peer,
that's
so
crushing
on
how
to
share
the
logs.
Let's
get
it
asks
over
and
over
and
over,
but
I
guess
we're
focusing
on
just
the
log
side
of
it.
But
you
know
it'll.
Last
the
same
eight
nodes
ten
times.
F
Well,
yes,
and
so
for
the
the
log
mode
that
we
got
to
consider,
there's
two
purposes
right.
So
there's
the
exceeding
your
peer-to-peer,
BitTorrent
download
thing
and
then
there's
also
the
oh,
give
me
the
random
block
from
block
whatever
in
in
the
past,
correct
right
so
and
I
think
both
of
those
need
a
multi-tier
architecture
system
right,
because,
if
I
have,
which
is
the
current
situation,
you
know
I
have
like
four
peer-to-peer
nodes
that
are
available
to
the
public.
F
If
I
don't
have
to
have
all
those
blocks
on
all
those
nodes,
but
there's
some
way
that
the
torrent
downloader
thing
knows
where
they
are
and
can
send
them
without
having
to
me
to
keep
all
those
copies
on
all
four
of
those
nodes.
That
would
be
great
and
same
for
the
apis,
so
the
apis
is
maybe
easier
solvable
quickly,
because
I
guess
Aaron
from
Gray
Mass
has
some
rules
that
know
how
to
do
that.
But
maybe
we
just
need
to
publish
that
as
a
recipe.
Well,.
D
D
Ultimately,
you
set
up
like
in
genes
where
it
had
this
kind
of
cascading
effect
and
the
light
history
API
would
knowingly
say:
I,
don't
have
it,
but
it's
not
that
I'm
404,
it's
that
I.
Just
don't
have
that
range
and
it
would
reply
back
to
engines
which
would
say.
Oh
that's,
a
I'm
gonna
say
418,
that's
I'm,
a
teapot,
that's
my
favorite
I'm,
a
418
and
then
engines
would
say:
okay,
try
the
next
note
in
line
and,
of
course
they
would
set
up.
D
You
know
and
I'm
a
firm
believer
in
that
when
they
did
the
research
that
it's
80,
20
80
of
all
your
load
is
in
the
last
30
minutes.
You
know
I
mean
very
rarely.
Do
you
ever
ask
for
the
old
stuff,
but
damn
when
you
do
it's
hard?
So
if
you
want
to
do
it
all
you
just
keep
throwing
terabytes
and
terabytes
of
block
logs
at
it,
because
everybody's
got
to
be
able
to
answer
so
they
did
it
with
custom
response
codes.
You
know,
I,
don't
know
you
know.
If
internally,
it
could
figure
out.
D
F
D
D
A
D
D
D
You
know
lease
cons
or
whatever
it
is.
You
know
the
dumb,
but
it
allows
me
to
fail
over,
but
I'll
be
honest.
It
doesn't
really
like
all
of
that.
Some
sometimes
sessions
will
kind
of
get
hung
up
if
I,
reboot,
one
or
the
other,
but
yes,
I,
do
I
I
try
to
h
a
proxy
it
because
I
mean
I'm
breaking
all
the
time.
You
know
yeah.
G
D
F
D
The
Quirk
is,
is
you
know
what,
if
you
got
one
node
OS
trimming
up
or
thinking
they're,
trimmed
and
archived
in
a
different
pattern
than
what's
there
I,
don't
know,
I
mean
I,
but
yeah
I
mean
I
I,
don't
stack
my
nose
peer-to-peer
the
same
network
on
the
same
node
like
that,
a
lot
of
times,
I'll
split
them
out
and
do
peer-to-peers
for
different
chains
if
they
can
handle
it
on
the
same
node,
so
it
wouldn't
have
me
personally.
I
would
be
using
like
an
iSCSI
Nas
or
something
between
them
and
yeah.
D
F
The
reason
I'm
running
an
API
note
in
a
peer-to-peer
node
on
the
same
machine,
because
then
the
historical
blocks.log
file
is
shared
on
ZFS
right.
So
when
you,
you
start
one
of
them,
you
put
the
back
up
there.
It's
got
the
full
block
log
and
then
you
go
to
start
the
other
one.
You
say
cop
snapshot
the
block
log
from
the
previous
one
here.
So
that
way,
the
history
up
to
that
point
is
shared
and
then
they
diverge.
F
G
Yeah
I
was
thinking
like
you
configure
one
to
be
a
full
node
with
a
sleep
directory,
and
then
you
can
figure
another
one
to
say
well,
you're
just
going
to
throw
them
away,
you're
running
a
truncated
block
log,
but
there's
there's
another
directory
out
here.
You
can
go!
Look
at
it.
If
you
want
to
see
if
there's
blocks
available
right
right,
so
it
would
never
write
to
there.
It
would
simply
be
okay.
I
I
can
go
look
here
if
I,
if
I
don't
have
something
in
my
local
and.
G
Of
like
the
master
and
the
other
one's
the
slave,
if
you
will
and
then
you
know
they,
they
could
run
that
way.
That
way
you
can
share.
You
can
have
as
many
shares
of
that
huge
block
log
as
you
wanted,
across
whatever
you're
doing
API
notes:
p2b
nodes,
whatever
you
know,
they're
just
all
share
this
little
spinny
disk.
D
Even
if
it's
not
the
huge
block
log
just
to
be
able
to
share
it
and
have
it
more
efficiently
use,
we
can
better
use
these
servers.
Like
say,
I
mean
I'm,
throwing
it's
got
plenty
of
CPU
threads,
it's
just
you
know,
so
you
could
throw
more
at
it,
but
then
you
just
got
to
throw
more
and
more
terabytes
of
space
at
it.
D
So
if
you
could,
you
know
have
like
a
Master
Slave
type
of
you
do
the
work
and
then
any
other
node
assumed
that
that
those
static
files
yep
are
clean
and
just
look
at
them
when
you
can
that,
yes,
that
would
definitely
let
us
better
use
a
lot
of
the
hardware
that
we
have.
We
have
fast
servers,
but
we're
not
using
all
the
threads
yeah.
D
F
Yeah
because
it
creates
all
these
so-called
merge
block
files,
which
is
you
know,
a
chunk
of
100
blocks
and
once
those
100
blocks
are
written
by
one
process,
then
any
of
the
other
diffuse
processes
in
the
ecosystem
can
read
it
from
the
shared
storage
and
in
diffuse
that
can
be
like
Google
Cloud
store
S3,
some
iSCSI
thing.
You
know
whatever
yeah.
G
Right
right,
the
the
other
thing
and
Stephen
you
might
want
to
take
a
note
of
this
I
know
in
in
our
original
peer
discovery,
a
proposal.
It
included
the
realizing
what
what
blocks
are
available
on
a
node
so
that,
when
you're
syncing,
it
would
only
go
to
then
peer
discovered
nodes
that
had
what
you
were
looking
for.
It
wouldn't
even
bother
going
in
places
that
didn't
because
it
would
know
it
would
know
what
everyone
had
available
when
it
was
doing
it.
It's
syncing.
E
B
G
A
A
Probably
the
people
saying
yes,
you're,
like
the
first
part
of
that
question,
not
so
much
the
second
just.
Would
you
want
to
ability
to
store
some
blocks,
a
different
location?
Yes,
and
is
there
another
way
you
want
to
be
able
to
share
blocks
between
those
yeah?
We've
got
no
here.
So
this
is
one
area
that
we
differ
on
the
survey
results
and
yes
to
for
nodes
that
serve
API
queries.
E
G
D
Well
I'll
say:
that's
a
whole
nother
ball
of
wax,
but
it's
just
the
other
ear
right,
but
it's
a
bigger
ear.
So
I
didn't
know.
If
that
was
part
of
the
scope.
I
know
we
really
kind
of
focus
on
the
log
side
of
it,
but
I
think
most
people,
probably
at
this
point,
I
won't
say
most
several
heavily
used
ship
I
do
think
a
lot
of
people
might
have
shifted
over
to
trace
after
the
fork
and
all
right.
D
D
F
D
I
can
tell
you
I
I,
don't
think
there's
a
way,
but,
like
my
monitoring,
stuff
I
have
to
scrape
the
node
OS
log
to
see
when
the
last
launch.
What's
in
that
state
history
well,
EOS
block
log
I
can
do
a
smoke
test,
but
management
of
State
history
is
somewhat
limited.
Although
it's
a
much
more
solid
recovery
product
break
the
crap
out
of
it
all
right
block
logs
is
okay,
I'll
fix
State
history,
but
it's
just
two
mountains
monstrous
log
files.
Hey
you.
E
A
E
E
A
G
In
I'm,
just
I'm,
just
a
little
surprised
and
so
I
went
and
looked
like
the
discussion
was
that
2.1
didn't
provide
the
ability
to
sleep
to
a
different
directory
and
it
sure
looks
to
me
like
it
did
now.
Obviously
I'm
just
looking
at
the
code
and
not
testing
it
I
think
it
didn't
work
somehow,
but
it
sure
looks
like
it
had
that
feature.
Yeah.
A
F
G
I'm
sorry,
there's
two
different
ones:
go
ahead:
there's
the
archive
which
yeah
I
wouldn't
look
at
it
again,
which
is
somewhat
dubious.
Why
you'd
ever
want
to
do
that,
but
I
mean
maybe
you
would
but
there's
the
retaining
directory,
which
should
then
go
ahead
and
look
at
that,
but
potentially
it
just
didn't
work
but
I
think
as
design.
There
was
the
idea
that
it
should
do
exactly
what
we
were
talking
about
now
again.
Maybe
it
didn't
work
for
some
reason,
but
yeah.
C
Hopefully
the
documentation
is
is
starting
to
improve
now,
because
we've
got
there's
a
lot
more
Synergy
happening
between
the
docs
team
and
the
developer
Advocates
and
the
engineers
and
I
think
there
was
that
at
block
one
there
there's
just
a
much
more
continual
pattern
of
weekly
meetings,
they're
involved
in
everything
they
hear.
What's
going
on,
so
hopefully
we're
closing
that
Gap.
Obviously
not
many
people
know
doc
studyosnetwork.com
exists,
but
it
does.
C
It
is
up
to
date
and
it
it
has
even
the
stuff
from
the
you
know,
3.1
Etc
et
cetera,
so
we
will
get
this
explained
better.
So
to
Kevin's
point
I.
Guess
there
was
there
was
an
archive
and
a
retain,
and
the
question
is:
if
you
ran
the
retain,
did
it,
let
you
look
at
where
those
were
swept
to
to
see
and
and
be
able
to
ref
reference,
those
I
don't
know.
G
Yeah
I
mean
academic
weather
worked
that
way
into
one.
We
can
certainly
make
it
work
that
way,
and
and
yes,
land
to
the
4.0
I
mean
if
it
doesn't
work
that
way,
it
should
be
trivial
to
make
it
work.
That
way
like
providing
a
different
I
mean
you
have
to
have
a
different
directory
restricting
that
to
the
same
like
Drive,
which
is
silly
so
there's
like
no
technical
reason.
Why
you'd
ever
do
that
now,
whether
we
did
on
accident
or
or
what
you
know
who
knows,
but
that's
I
mean
that's
that
yeah.
F
G
That's
what
it
sounded
like
and
and
as
well
like,
if
we,
if
we
do
the
feature
of
like
being
able
to
share
then
again,
not
making
that
a
configuration
thing
makes
that
much
easier
right.
You
don't
have
to
like
actually
a
line
and
everything
so
yeah
I
think.
Maybe
we
should
just
hard
code
that
you
guys
have
a
a
a
a
a
number
you
you
love,
I
heard,
a
hundred
which
seems
awful,
small
I
would
think
more
like
10,
000
or
or
something
like
along
those
lines.
Any
commentary
there.
D
G
Just
want
to,
like
you
know
the
what
Ted
mentioned
about
high
nodes
right
I
mean
you,
you
could
put
each
block
in
each
file,
but
you
don't
want
200
000
inodes
right
on
on
areas
where
you're
doing
that
sort
of
thing.
So
you
know,
obviously
you
want
you.
You
want
fairly
big
size
files,
I
think
just
to
cut
down
a
number
of
like
open
file
handles
you
have
and
and
I
know
what
you're
using
that's
the
other
thing.
G
A
G
D
C
D
C
C
C
You
know
kind
of
write
the
code
once
and
have
it
apply
to
shipblog
and
block
log,
and
he
found
enough
differences
between
the
two
log
types
that
he
started
to
back
away
from
that
the
concept
should
be
the
same,
that
we
will
split
the
ship
blogs
as
well,
the
state
history
logged
and,
and
they
will
have
different
blocks
and
we'll
use
a
constant
block
side
for
the
Swarm
later.
If
I,
don't
I,
don't
know
if
you
need
those
in
this
form
or
not,
but
the
I.
D
Got
to
imagine
interesting
info
about
that,
but
I
don't
know
if
you'll
swarm,
State
history
logs,
because
they
you
won't
get
a
different
block
log,
you
can
have
a
different
state
history.
Log
on
okay,
I've
had
two
different
servers.
Getting
in
my
farm,
give
me
two
different
results
and
it's
a
trace.
History,
debugging
I,
think
something.
G
D
For
the
sake,
what
it
did
is
it
broke
Atomic
assets
because
it
refused
to
accept
it
as
a
whatever
it
was.
It
said
this
is
not
valid,
but
it
was
valid
because
it
was
just
different
and
it
probably
was
not
thrilled
in
the
fact
that,
oh
you
keep
guarantee
consistency
across
state
history.
It's
about.
It's
consistency
are.
C
D
One
question
or
not:
question
I'll
assume
it'll
be
accounted
for,
but
it
may
spin
off
into
a
whole
nother
code
set.
Is
you
know
when
you
restore
from
a
snapshot?
It,
ultimately,
I
don't
know
validates
keeps
it.
You
know
whatever
make
sure
that
the
snapshot
restore
process
doesn't
jam
up.
I,
don't
know,
maybe
it
won't.
Maybe
it's
just
looking
at
the
current
block,
but
that
just
you
know
like
I
say
it's
as
you
start
moving
all
this
stuff
around.
We
use
snapshots
and
stuff.
D
You
know,
anytime,
it
crashes
or
or
sometimes
just
you
have
to
do
it
to
reboot
it.
If
you're
staying
you
reboot
your
server
you're
launching
from
a
snapshot,
it
uses
that
10,
FS
or
whatever
so
think
about
how
the
snapshot,
restores
and
validation
would
ever
go
into
it
and
I
would
also
just
maybe
as
you're
into
the
block
log
side
of
it.
D
D
D
C
Cases
so
well
I'd
like
to
return
the
thank
you
and
say
thank
you
for
joining
all
these
calls
every
Wednesday
Michael,
your
experience
is
invaluable
and
we
we
really
need
people
that
beat
on
this
stuff
experiment
with
it.
Try
it
on
every
different
configuration
of
hardware,
and
you
do
all
those
things.
So
thank
you
right
back
to
you.
No.
A
A
A
D
About
one
thought
I
maybe
had
was
you
know?
Maybe
you
could
alternate
you
know,
because
we
don't
need
every
week
being
a
technical
discussion
and
every
week
being
an
upgrade
discussion,
but
you
know
kind
of
focusing
more
on
hey
upgrades
features
stuff
like
that,
maybe
and
then
every
other
week
trying
to
coordinate
more
of
the
VPS.
You
know
we
had
some
of
the
additional
VPS
joining
in
here,
the
highly
technical
ones
early
on
but
I
mean
every
week.
You
know
I
mean
since
yeah.
E
D
D
You
know
impactful
thing
one,
maybe
do
some
surveys
to
the
exchanges
in
the
that
side
of
things,
but
then
also
you
know,
maybe
we
can
try
to
press
a
little
harder
and
BPS
will
see
oh
they're
actually
trying
and
see.
If
we
can
get
some
more
people
to
come
in
here,
I
I
didn't
get
a
chance
to
recruit
many
people,
but
I
do
think
that
there
are
probably
some
more
smart
people.
D
E
C
C
Maybe
if
Stephen
were
to
whip
out
the
the
program
backlog
I
mean
he's,
got
you
know
and
I
don't
know
Steven.
If
you
have
anything,
that's
tagged
like
Words,
more
block
producer
or
infrastructure
versus
you
know
like
developer
I,
don't
know
if
there's,
if
you
have
anything
tagged
that
way
where
you
could
kind
of
like
show
people
what
the
backlog
is.
What's
going,
you
know
what's
planned
in
3-2,
what's
planned
in
three,
you
know
in
the
4.0
or
whether
it's
3.3
the
what
I
call
the
March
April
release.
C
If
that
would
be
interesting
to
people
to
see
like
the
actual,
it's
all
open
source.
So
you
guys
it's
all.
You
know
in
the
EOS
Network
Foundation
program
management
repos.
Some
of
you
guys
may
not
like
to
dig
through
all
that,
but
if
that
would
be
exciting
to
see
what
Stephen
really
kind
of
has
put
together,
that's
not
a
an
issue.
C
I,
don't
know
Steven.
If
you
know
of
anything,
that's
pending
right
now
that
we
even
have
for
another
technical
discussion,
we
need,
if
you
have
anything
top
of
mind,
but
again
we
can
share
stuff
that
might
encourage
more
block
producers
to
want
to
jump
on
and
hear
what's
going
on,
which
may
then
cause
them
to
trigger
a
like.
Oh
my
god,
I've
been
forgetting
about
this
I
want
to
ask
you
for
this
requirement
and
or.
D
E
C
B
Not
at
the
moment-
and
let
me
add
in
a
few
other
thoughts
so
right,
quick,
the
stratification
across
those
different
stakeholder
groups
is
not
a
dimension
that
we've
put
inside
of
the
program
management,
but
it's
absolutely
an
opportunity
that
I'll
address
across
the
next
couple
of
weeks.
The
other
thought
I
wanted
to
present
here
is
just
I
think
this
is
a
great
forum
for
identifying
the
opportunities
to
establish
those
next
discussions.
B
The
one
risk
I
want
to
be
cognizant
of
is
that,
while
this
is
a
great
time
for
many
block
producers
to
be
able
to
come
in
and
provide
that
input,
there
may
be
some
discussion
topics
that
are
challenging
for
the
core
enf
team
to
attend.
We've
just
got
some
West
Coast
folks,
and
this
would
be
a
bit
of
a
stretch.
So
what
I'd
like
to
do
is
maybe
use
this
forum
as
an
opportunity
to
identify
those
discussion
topics
and
then
based
off
the
group
that
we
need.
B
We
can
either
queue
it
up
specifically
for
this
time
slot
or
we
can
identify
a
separate
time
slot
where
we
can
get
the
people
that
we
need,
but
like
the
model
of
having
these
forums,
I
think
is
just
like
extremely
valuable,
so
we
should
keep
doing
this
and
I
will
work
on
getting
those
Dimensions
stratified
across
how
we're
managing
these
larger
initiatives.
So
people
can
start
poking
around
in
the
space
that
I've
been
living
in
yeah
I.
C
Mean
one
of
the
issues
is
we,
you
know
we
have
Max
on
here
and
it's
probably
late
in
the
evening
for
Max.
If
we
were
to
move
it
to
say
one
which
lets
us
pick
up.
Our
eggs
like
at
times
where
we
need,
like
a
you
know
like
Kevin,
is
a
great
proxy.
So
Kevin
can
handle
a
lot
of
these
questions.
But
let's
say
we
had
something
that
was
really
critical,
that
we
need
our
eggs
opinion.
C
So
I
think
that's
what
Steven's
touching
on
is
the
sensitivity
of
where
a
global
organization
and
we're
always
there's
no
way
to
avoid
always
excluding
some
region
of
the
world
without
these
people
calling
in
at
2AM
or
something,
and
so
we
would
just
have
to
try
to
optimize
towards
hey.
This
is
more
important
that
we
get
Eric
on
the
call
or
hey.
D
Right,
that's
what
I'm
saying
what
ends
up
happening
is.
Is
that
when
you
go
to
any
other
slot,
you
almost
at
least
one
zone,
but
that
was
it
because
I
said
the
same
thing:
I
always
I
mean
I'll,
make
fun
of
being
American,
but
you
know
I,
I,
hate,
missing,
Ross
and
general
Rios
and
there's
a
lot
of
tilos
crew.
That's
actually
over
on
the
Eastern
side,
too,
heavy
technical
that
that
would
love
to
be
involved,
so
I'm
definitely
open
for
it
I
mean.
Maybe
we
can
flip-flop
and
do
one.
A
B
Go
ahead,
oh
I
was
gonna,
say
right.
The
key
is
just
the
intentionality
here
right,
like
we
identify
the
opportunity
in
this
forum.
We
then
evaluate
who
the
key
stakeholders
are,
and
that
also
gives
us
a
Runway
to
kind
of
get
the
word
out.
You
know
there
wasn't
really
a
ton
of
activity
around
this
first
instance
to
really
make
sure
that
everybody
would
come
and
discuss
this,
but
if
we
get
a
little
bit
of
a
calendar
rolling,
that's
how
you
drive
this
level
of
Engagement
we're
looking
for
and
then
somebody
will
be
like.
B
A
C
Do
you
feel
there's
any
value
Stephen
to
going
through
the
backlog?
Just
at
any
level,
you
feel
is
appropriate
to
show
people
how
structured
things
are
because
I
mean
you
know
not.
Everyone
on
this
call
has
seen
the
level
of
work
that
is
going
into
this
and,
and
you
know,
accuracy
Etc,
maybe
it's
too
much
more
geared
towards
developers
than
infrastructure,
but
is
there
any
value
in
just
letting
people
see
like
hey?
This
is
all
open.
It's
transparent!
You
can
go
look
yourself,
but
you
know
here's
where
it
lives.
Here's
how
we
go
through
it.
C
It's
it's
program,
management,
it's
not
code,
it's
open
issues
and
it's
how
the
issues
are
tracked
and
prioritized.
So
it's
it's
really
more
program
management
or
project
management,
but
it
would
show
you
like
how
we
track
all
the
issues.
All
the
issues
are
written
in.
You
know
in
English,
unfortunately,
they're
not
we
don't
translate.
Them
also
shows
you
where
there
are
product
briefs
and
links
out
in
some
cases
to
the
product.
C
Briefs
of
this
is
the
description
of
this
product,
so,
like
Steven,
took
a
bunch
of
notes
today
from
this
call
and
those
are
now
written
down
as
requirements
that
will
go
into
building
up
this
block
log
and
ship
log
splitting
and
so
you'll
see
like
here's,
where
that
is
here's,
how
we
look
at
here's,
how
we
assign
it
to
the
group,
that's
going
to
do
it
and
all
the
rest
of
that.
The
whole
point
is
we
want
to
present
more
transparency
way
more
than
block
one
ever
did
right
of
like
this
is
what
we're
doing.
C
D
How
we're
doing
it
yeah
I,
would
say
as
an
organized
you
know,
strategy
you
know
definitely
look
this
is
you
know
what
we're
doing
show
it?
It
would
give
a
recording
to
at
least
kind
of
drop
out
to
the
BPS
all
around
the
world.
To
say.
Look,
you
know,
I
mean
here's
an
easier
way
to
kind
of
Wade
through
all
the
GitHub
issues
and
have
some
commentary
to
it.
So
definitely
I
think
useful.
Is
it
a
topic
on
one
of
the
technical
calls?
Maybe
you
do
it
before
it
and
could
kind
of
do
it?
B
I
think
and
what
I'd
say
about
it
right
now
is
that
I'm
happy
to
share
where
we're
at
I
will
be
very
transparent
in
showing
that
it's
it's
quite
top
down
at
the
moment.
That
is
to
say
that
these
initiatives
are
quite
large,
as
well
as
the
statuses
like
we're
still
hardening
right.
It's
a
very
iterative
process
and
we're
working
on
getting
sign
on
on
how
product
management
happens
here
at
EOS,
Network
Foundation,
but
I'm
happy
to
give
you
guys
exposure
to
where
we're
at
in
that
Journey.
D
Problems,
yeah,
there's
a
lot
of
different
branches,
there's
a
lot
of
different
pieces
and
that's
what
I
was
thinking
even
kind
of
streamlining
it.
You
know,
at
least
with
some
of
these
more
repetitive
types
of
you
know,
pieces
where
you've
got
that
or
I
think
you
have
a
mechanism
to
rate
the
highest
thing
right,
how
block
log,
how
peer-to-peer,
splitting
or
or
the
efficiency
and
using
that
as
much
of
that
way,
you're
not
having
to
say
all
right,
here's
the
whole
damn
Playbook
again
and
here's
where
we're
at
definitely
do
it.
D
You
know
and
promote
it
and
data
dump.
You
know
hey
catch
up
where
at
all
we're
working
on
some
of
it's
high
level,
not,
but
that
will
drive
everybody
to
vote
on
whatever
type
of
mechanism
we
can
get
out
there.
That
say
look
this
is
really
important
to
me
and
that
will
then
help
us
drive
a
calendar.
D
B
Yeah
and
that's
the
goal
right
is
that
we
do
want
more
exposure
and
activation
of
people
interacting
with
how
we're
prioritizing
and
talking
about
our
work
I'm.
Just
you
know,
product
person
trying
to
manage
the
expectations
of
the
level
of
detail
that
we
have
across
the
board
we're
moving,
absolutely
directionally,
correct
and
I'm
happy
to
kind
of
take
that
initial
step.
I.
Just
you
know,
I
I
I
want
you
guys
to
also
have
I.
D
C
C
You
want
compared
to
block
one.
This
transparency
is
phenomenal
and
the
hope
is
when
we
take
you
through
it.
It
jogs
things
in
your
memory
so
like
if
Daniel,
if
we
could
get
Matthew
to
join
just
next
week,
just
to
listen
to
what
Steven's
going
to
tell
you
know
and
show,
because
if
it
triggers
an
idea
of
like
oh
I've,
been
meaning
to
say,
I
want
this
feature.
I
need
this
fixed
going
through
this.
C
If
it
triggers
things,
that's
why
you
know
it'd
be
great
if
Ross
or
or
Corbin
were
able
to
join,
because
if
it
triggers
more
ideas
that
have
been
saying
laying
there
latent,
because
you
figured
No,
One's
Gonna,
listen
anyway,
then
we've
achieved
something
because
now
we're
starting
to
get
the
flow
coming
in
of
saying
hey
since
you're
listening,
you
know,
I've
always
felt
we
should
do
this.
Like
Matthew
pointed
out
hey.
This
is
an
issue
I
hope
open
months.
You
know
whatever
blah
blah
blah.
C
You
know
hey
great
now
that
you're,
finally
addressing
this
issue,
we
did
try
to
go
back
and
address
a
bunch
of
issues
and
and
oci
cleaned
out.
Hundreds
literally
hundreds
of
of
backport
issues
that
people
had
put
in,
but
there's
probably
there
was
some
point
where
people
got
tired
of
just
opening
issues
that
were
never
going
to
be
addressed
and
so
like.
C
We
want
to
take
people
back
out
of
that
of
of
there's
no
point
in
asking,
because
no
one's
listening
now
that
we
clearly
are
listening,
hopefully
it'll
trigger
some
more
requirements
coming
in
and
we'll
be
able
to
literally
address
those
because
making
this
one
of
Eve's,
North
Stars,
is
and
we're
we're
very
very
far
away
from
this
is
blockchain
Made
Easy.
That
should
make
some
of
you
laugh,
because
it's
not
easy,
and
so
with.
D
C
With
that
as
a
North
star,
hopefully
some
of
you
could
say
if
you
could
fix
this,
it
would
make
it
easier
and
that's
why
we're
trying
to
collect
these
requirements
and
in
a
lot
of
cases.
I'll
be
honest.
This
is
not
a
plug
for
oci.
A
lot
of
these,
the
oci
team,
has
put
their
hand
up
and
said:
hey
we
get
it.
We
understand
it.
We've
worked
on
that
area
before
just
shoot
it
over
to
us
and
they'd
knock
it
out.
I
mean
like
right
away.
It's
not
a
matter
of
you
know.
C
Oh
prioritize,
this
over
that
they're
just
a
machine.
You
know
it's
the
compliment.
It's
not
probably
not
a
compliment
to
call
someone
a
machine
but
they're,
truly
just
a
machine
and
we
feed
stuff
in
and
it
gets
pounded
out,
and
so
that's
why
we're
hungry
to
let's
make
blockchain
Made
Easy,
let's
fix
this
stuff,
and
what
we
need
to
do
is
trigger
those
memories
of
where
you
guys
shut
down
from
no
one
listening
to
you
in
the
past
and
get
those
addressed.
E
A
B
A
B
A
C
At
least
make
it
an
hour
on
the
days
where
we
know
we
have
kind
of
an
extended
agenda,
so
hopefully,
next
week
should
probably
be
an
hour
okay,
it
really
does.
You
know,
initiate
some
good
conversation,
because
the
status
is
probably
10-15
minutes
and
and
then
the
extended
conversations
are
what
drag
us
through,
which
is
super
valuable.
This
I
enjoyed
every
minute
of
this
call.
So
thank.