►
From YouTube: Filecoin Core Devs Biweekly #23
Description
Recording for: https://github.com/filecoin-project/tpm/issues/55
For more information on Filecoin
- visit the project website: https://filecoin.io/
- or follow Filecoin on Twitter: https://twitter.com/Filecoin
Get Filecoin community news and announcements in your inbox, monthly: http://eepurl.com/gbfn1n
A
All
right,
good
morning,
good
afternoon,
everyone
welcome
to
the
falcon
core
devs
meeting
number
23.,
it's
thursday
july
29th.
Thank
you
all
for
being
here.
We've
got
a
fairly
regular
agenda
today,
updates
from
all
of
the
teams,
a
couple
of
introductions
to
make,
and
at
least
one
point
of
discussion
in
terms
of
what
should
we
do?
What's
the
next
way
we're
going
to
be
approving
the
falcon
protocol,
but
we'll
get
to
that
in
in
good
time?
For
now,
let's
get
started
with
updates.
A
Let's
see
who
wants
to
go
first,
maybe
fujon.
Do
you
want
to
go
sure.
B
Thank
you
good
day,
everyone
so
for
the
fukuon
we
had
achieved
a
couple
of
interesting.
Let's,
let's
say
this
way
milestones
so
yesterday,
we've
been
able
to
finish
with
all
the
fixes
needed
to
be
done
to
the
api
and
market
clients
in
order
for
them
lotus
miner
to
be
interoperable,
with
foucault
note
on
interrupt
net.
So
currently
it's
been
able
to.
B
Do
deal
storage
deal
on
video
deals,
and
but
there
is
a
problem,
another
problem
related
to
ep2p.
There
is
some
issue
on
the
on
the
gossip
protocol
in
the
glossy
protocol
that
we
are
currently
figuring
out.
Basically,
I
have
already
mentioned
it
to
ayush.
Yesterday.
The
problem
is,
after
establishing
a
connection
to
ghost
ship
sub
channel.
B
Focal
node
is
not
receiving
messages
after
four
to
five
seconds
and
we
are
currently
working
out
on
finding
out
the
reason
for
such
behavior,
which
is
completely
not
not
clear
why
it's
happening
and
then-
and
this
problem
only
happens
on
the
internet,
but
the
possible
reason
for
that
is
because
on
on
the
interrupt
net,
we
are
only
using
single
node
to
communicate
to
which
is
a
lotus
node
controlled
by
us.
B
So
that
might
be
a
hint
for
resolving
the
issue,
so
we
are
currently
still
instigating
and
figuring
out
what
what
might
be
the
reason
for
that
yeah.
We
have
also
introduced
the
improvements
to
our
old
miner,
not
the
lotus
miner,
but
the
coal
miner,
which
we
are
currently
developing.
B
We
have
introduced
the
improvements
in
order
to
in
order
for
our
miners
to
work
with
batching,
which
was
introduced
into
lots
winery
recently
yeah,
and
we
are
currently
testing
testing
it.
We
have
possibly
found
one
issue,
I'm
not
sure
is
it
on
the
lotus
level
protocol
level,
or
only
one
we're
currently
investigating
that,
and
if
I
will
have
more
information
on
that,
I
will
of
course
make
sure
to
acknowledge
everyone
with
it
yeah.
B
We
are
also
preparing
for
the
audit
and
preparing
the
guidelines,
codeworks
and
proper
onboarding
procedures
for
the
people
who
want
to
try
out
for
home
not
as
actively
though,
but
there
are
currently
several
issues
need
to
be
resolved
first,
so
yeah
that
seems
to
be
the
current
status
for
the
focal
node
yeah.
I've
also
mentioned
on
the
previous
meeting
that
we
had
an
issue
with
brittle
memory
management
and
we
have
free,
establish
the
note
on
a
dedicated
machine,
not
a
virtual
machine,
and
as
of
now
it's
working.
B
A
Sounds
good
thanks
a
lot
yeah!
That's
that's!
Definitely
good
news
and
good
to
hear
two
weeks.
Two
weeks
is
a
nice
long
period,
and
I
know
that
there
was
a
lot
a
lot
of
bugs
that
needed
to
be
fixed
in
order
to
get
there
yeah.
Regarding
the
regarding
the
connection
issues
between
lotus
and
pujol,
non-interrupted
yeah,
that's
definitely
weird.
We
talked
about
this
yesterday.
A
I
suggest
trying
to
connect
to
the
bootstrappers
directly
and
seeing
the
interrupt
bootstrappers
directly
and
seeing
what
that
does
but
yeah,
given
that
it's
only
happening
on
this
kind
of
unique
network.
It's
probably
not
a
too
much
of
a
concern,
we'll
see
what
happens
cool
any
questions
for
maxine
cool
I'll.
Tell
you
venus
books.
Can
I
get
an
update.
C
Okay,
yeah.
Thank
you,
irish
hello,
everyone
yeah
for
villas
yeah.
Last
two
weeks
we
are
yeah.
Our
video
major
work
is
about
the
the
incubation
project
and,
as
we
mentioned
before,
we
launched
the
incubation
project
with
the
four
confrontation
together
and
I
think
yeah
the
last
okay,
the
first
milestone
to
yeah
to
to
get
in
about
15
miners
and
to
join
us
yeah.
C
Currently
we
got
more
than
20
applications
and
I
think
it's
good
now
we're
working
on
to
ask
yeah
to
help
clients
to
join
the
falcon
network
via
the
venus
incubation
common
services
yeah.
We
took
a
lot
of
time
to
do
the
hands-on
support
for
our
our
users
regarding
the
basic
knowledge
of
the
falco,
and
also
the
architecture,
the
common
lines
and
so
on.
Currently
we
have
yeah.
We
have
discussed
a
lot
with
users
from
those
american
europe
and
asia.
C
After
a
few
days,
we
have
two
users
successfully
connected
to
the
yeah
and
start
to
grow
the
power
you
know,
which
is
good
and
what
was
working
on
other
users
and
early
on
yeah.
Besides
working
on
this
we're
also
working
on
the
endo
user
document
and
because
we
found
that
many
many
users
still
have
some
difficulty
to
really
install
their
system,
including
about
the
theater
and
the
worker,
and
how
you
connect
to
the
common
service.
C
C
And
also
we
are
still
working
on
some
some
enhancements.
For
example,
we
have
yeah
for
the
vlasm
messenger
and
we
have
access
limitation
to
prevent
the
dos
attack
because
which
is
on
the
other
cloud.
You
know-
and
you
know,
what's
more
yeah
fix
some
bags.
Actually,
if
we
don't
vote
for
the
videos,
one
is,
and
now
we
found
that
back
about
the
an
f3
address,
validation
and
now
it's
yeah.
It
is
fixed
yeah
for
the
coming
weeks.
C
We'll
continue
to
connect
more
users
into
the
incubation
platform
and
we
start
to
think
about
how
to
share
the
block
reward
for
the
whole
pool
yeah
so
that
yeah
even
for
small
monitors,
they
could
have
some
certain
yeah
income
every
day.
This
is
one
thing,
and
another
thing
is
that
we're
thinking
about
the
market
to
get
the
as
real
deal
and
you're
either
yeah.
That.
C
Okay,
we
are
planning
to
do
okay.
I
think
that
yeah,
that's
all
any
christians.
A
Nice,
that's
a
lot
you
have
going
on
one
quick
question:
maybe
I
missed
it.
So
how
much
is
there
mining
power
on
the
falco
network
today?
That's
relying
that's
relying
on
the
venus
minor
and
venus
mode,
and
if
so,
do
you
have
a
sense
of
how
much
it
is.
C
There
is
yeah,
the
proportion
of
the
last
part
is
not
yeah.
That's
so
big!
I
I
was
thinking
there
are
about
okay,
thousands
of
miners
working
yeah,
very
well
as
the
software
yeah
to
connect
to
the
top
network.
Perhaps
I
will
send
that
there
will
be
next
100
tinabytes
hard,
close
yeah,
not
too
much.
We
need
to
yeah
do
more
work
on
this.
A
Yeah,
I
mean
100
better
ways,
there's
a
lot.
It's
a
lot
in
regular
terms,
it's
just
small
for
the
five
point
network,
but
that's
good
any
other
questions
for
stephen.
A
All
right
cool
forest
folks.
What
have
you
all
been
up
to.
D
Oh,
hey
guys,
yeah.
We
have
quite
a
bit
of
progress
since
the
last
time.
As
far
as
the
audits
are
concerned,
then
most
of
the
f4s
are
complete.
Just
a
few
three
are
remaining
one
of
our
team
members
is
on
vacation
at
the
moment,
including
eric,
so
once
they
come
back,
I
think
we
should
be
able
to
complete
them.
I
believe
for
some
of
the
f4s
for
the
audit.
D
Eric
is
in
touch
with
the
security
team
and
dudley
from
the
file
coin
foundation
right,
and
I
think
they
need
to
be
sorted
out
together.
As
far
as
I'm
understanding
yeah
apart
from
the
fors,
there
are
some
we
had
some
very
good
engagement
with
the
russ
community
and
I
think
hunter
will
be
able
to
talk
more
about
that,
and
he
will
also
give
some
more
updates
on
it.
Hunter.
F
Yeah
so
on
the
russ
community
and
yeah
we've
been,
you
know,
doing
doing
some
engagement
on
that.
We
put
out
like
a
little
like
help
wanted
section
on
the
this
week
in
rust
newsletter,
and
some
people
from
the
community
have
been
kind
of
jumping
in
and
working
on,
kind
of,
improving
their
blockchain
shops
in.
In
addition
to
you
know,
contributing
to
just
a
little
lingering
issues
we
nice
to
haves.
F
You
know
that
we've
been
sitting
around
in
our
backlog
for
a
while,
so
that's
been
really
fun.
Also,
we
in
in
slack,
there's
also
been
a
few
asks
from
the
rust
community
and
and
people
building
falcone
clients.
I
guess,
and
they
we
we
built
a
like
a
rpc
api
client
and
we're
going
to
be
publishing
that
it's
kind
of
similar
to
in
concept
to
the
the
ipfs
api
crate.
F
F
Probably
next
week
and
it'll
be
really
good
for
their
for
for
folks
who
want
to
build
file,
coin
applications
on
rust,
and
it
should
work
for
both
lotus
and
forest
anything
implementing
falcoin
protocol,
but
there's
also,
you
know
we
were
kind
of
curious
as
to
what
how
much
of
our
interface
implements
falcon
protocol,
and
so
I
also
did
some
work
on
some
document.
Basically
documenting
force
api
coverage.
We
have
a
pr
we're
about
to
merge
that
validates
force.
Rpc
api
against
lotus's,
open
rpc
schema
on
build.
F
G
F
Finally,
we're
we're
not
yet
back
on
may
not.
There
was
some
lingering
some
consensus
issues
that
we're
expecting
moving
on
next
week,
once
there's
eric's
back
we're
also
reviewing
our
strategy
around
how
we
handle
network
upgrades,
such
as
having
an
instance
for
development
on
a
calibration
and
interop
net,
because
we
would
like
to
certainly
like
to
get
better
at
handling.
You
know
network
upgrades.
A
Cool
very
cool,
there's
a
lot
there
yeah
that
that
tool,
that's
kind
of
definitely
sounds
nifty,
it's
just
kind
of
scraping
api,
endpoints
and
trying
to
find
dissimilarities.
A
while
ago
in
this
meeting,
we
talked
about
trying
to
standardize
those
endpoints
across
the
implementations,
and
so
that'll
definitely
be
useful.
A
If,
if
we
do
want
to
push
in
that
direction
and
a
quick
question
for
the
two
of
you
and
maybe
also
for
like
zen
grand
here,
I
know
that
some
of
the
outcomes
of
your
audits
were
issues
that
were
kind
of
more
the
the
actors
code
and
therefore
the
filecam
protocol
itself.
What's
the
status
of
that,
are
we
and
are
we
actively
working
on
any
of
them
or
where?
Where
is
that
being
tracked?.
D
For
the
do
you
know
which
are
the
f4s,
because
I
think
that's
a
question
that
maybe
eric
will
be
able
to
answer
that
much
better
like
as
far
as
I
know
from
the
board
here,
maybe
if
I
say
the
names,
the
ones
that
are
there's
an
inconsistent
beacon,
entry,
validation
across
forks
and
inconsistent
decentral,
dc,
realization
of
randomness
and
denial
of
service
via
panic
and
block
validation.
So
these
are
the
ones
that
are
pending
on
our
side
and
we
should
be
able
to
close
it
in
the
next
coming
weeks.
D
H
You
very
much
cool
one
one,
one
other
question
so
as
part
of
hyperdrive,
we
from
lotus
spectactors
were
able
to
get
test
vector
generation
off
the
ground,
and
I
know
a
big
goal
of
that
was
to
allow
the
forest
team
to
to
use
this
as
part
of
your
strategy
for
minimizing
consensus,
differences
and
bugs
around
upgrades.
I'm
wondering
have
you
guys,
like
included
this
and
part
of
your
upgrade
planning
strategy,
or
have
you
integrated
test,
vector,
running.
F
I
I
have
a
question:
do
do
we
have
an
idea
of
when
our
next
fork
will
be,
or
our
next
network
upgrade,
because
the
reason
I
ask
it
because
it
would
be
really
cool
if
we
could
just
kind
of
use
that
as
an
opportunity
to
do
some
knowledge
sharing
on
our
end,
so
that
we
can,
you
know,
get
better
at
that.
A
Yeah
a
short
answer:
no,
but
let's
talk
about
that
once
we're
once
we're
done
updates,
because
I
think
that'll,
that's
a
natural
question
for
kind
of
this
group
to
be
talking
about.
So,
let's
put
a
pin
in
that
for
now.
Yeah
cool,
real
quick
for
lotus
updates.
Jennifer
couldn't
be
here,
so
she
gave
me
a
little
blurb
for
me
to
read
out
so
we
shipped
lotus
one
eleven
zero.
This
was
a
whole
lot
of
dev
work
kind
of
since
late
march,
early
april.
A
I
think
that
had
just
been
like
waiting
in
the
testing
pipeline,
because
we
were
testing
out
these
network
upgrades
and
then
testing
out
the
hyperdrive
upgrade
as
well.
So
all
of
that
finally
got
tested
post
hyperdrive,
some
bugs
were
caught
and
that's
that's
been
shipped
and
we
encourage
folks
to
check
it
out.
There's
honestly
too
much
to
mention
in
in
one
eleven
zero
itself.
We
also
just
began
the
111
one
testing
pipeline,
so
I
think
rc,
the
release
candidate
has
been
cut.
A
The
exciting
things
in
111.1
are
split
store,
which
we've
talked
about
in
this
group
before
just
basically
having
a
separate,
hot
and
cold
store
and
eventually
leading
the
online
garbage
collection,
so
that
people
that
only
want
maintaining
state
for
I
don't
know
one
week-
can
just
do
that
seamlessly
right
now,
it's
an
entirely
manual
process,
which
is
obviously
painful
and
the
other
big
one
in
it
is
the
new
miner
runtime
architecture.
A
It's
kind
of
we've
talked
about
that
in
this
group
as
well
yeah,
so
we're
hoping
that
that
will
lead
to
a
better
deal
stability
and
just
generally
more
storage
providers,
accepting
deals
on
the
falcon
network.
All
of
this
is
kind
of
moving
towards
an
ecosystem
milestone
which
is
hackfest
which
we're
going
to
be
participating
in.
So
we
kind
of
wanted
to
get
a
lot
of
this
work
ready
for
then
hackathon
starts
soon,
and
maybe
it's
already
started,
but
yeah.
A
So
that's
kind
of
what
this
sprint
was
towards,
and
so
we're
very
excited
to
see
what
people
build
in
hack
fs
and
what
feedback
we
get.
That
kind
of
thing,
I
think,
that's
about
it
from
the
lotus
side
of
things
yeah,
let's
get
to
updates
from
the
foundation,
maybe
the
first
one
we'll
do
is
to
introduce
caitlyn
beagle
to
the
rest
of
the
group.
A
I
Yeah
thanks
ayosh,
it's
really
nice
to
meet
all
of
you.
I've
been
looking
forward
to
joining
this
call
for
the
first
time
since
joining
last
week,
I'm
actually
coming
to
the
foundation
from
the
technical
university
of
munich,
where
I
actually
was
on
more
of
the
governance
side,
working
on
emerging
technologies
and
innovation,
governance,
and
I'm
now
going
to
be
putting
that
into
practice
here.
So,
hopefully,
some
bigger
visions
coming
down
the
pipeline,
but
immediately
we're
going
to
be
focused
on
actually
getting
our
fips
process.
I
Discussions,
sort
of
corralling
all
of
the
different
ideas
and
endpoint
input,
points
that
we
currently
have
on
slack
and
twitter
and
everywhere
else
into
sort
of
a
more
organized
format.
So
it's
easier
to
engage
with
issue
areas,
but
also
longer
term
ideas
as
well.
Yeah
you're
welcome
to
reach
out
on
out
to
me
on
slack.
If
ever
you
need
it
and
I'm
looking
forward
to
getting
to
know
you
all.
A
Fantastic
welcome
caitlin.
Thank
you
very
much
for
joining
us.
I
think
you've
already
been
added
to
the
phil
implementers
channel,
which
is
generally
where
this
group
of
people
coordinate
so
yeah,
feel
free
to
say,
hello
and
looking
forward
to
working
with
you
yeah
see.
Dudley
was
an
update
that
you
wanted
to
share
from
security
side
of
things
at
the
foundation.
G
Not
particularly,
I
want
to
say
that
the
this
is
a
general
thing.
The
bug
money
program
is
now
up
to
date
and
we
are
handling
it
when
implementers
feel
that
they're,
you
know
when
they've
passed
out
audits
and
when
they're
at
their
1.0
or
whatever
they
want
to
say.
You
can
indeed
join
us
so
ping
me
if
you're
already
ready
for
that
otherwise
I'll
be
reaching
out
thanks.
A
Excellent,
thank
you
cool,
any
questions
about
updates
or
anything
else
kind
of
related
to
what
we
talked
about
before
we
jump
into
other
points.
A
Sounds
good,
some
quick!
Well
one
quick
housekeeping
item,
so
the
folk
from
fujon
reported.
I
think
two
meetings
ago
that
lotus's
pride
that
the
price
the
gas
pricing
on
interrupt
net
was
borked
because
lotus
was
doing
it
incorrectly
and
the
network
was
kicked
off
using
interrupt
net
so
that
pro
that
has
since
been
fixed
in
lotus,
thanks
zen
grant
for
the
fix,
and
so
I
put
in
a
request
to
reset
interrupt
net.
A
I
assume
everyone
here
is:
okay
with
that
so
now
to
be
reset
and
have
correct
gas
values,
it'll
be
starting
from
b5
actor,
so
network
b13
again,
but
all
of
that
is
open
for
discussion
or
negotiation.
If
that's
not
what
we
want,
I
just
assume
that
would
be
best
any
objections.
A
Cool
sounds
good.
Yes,
I've!
Let
inferno
of
the
request,
I'm
sure
they'll
get
to
it
whenever
they
do
it's
not
the
highest
priority
item.
So
I
think
the
next
thing
I
wanted
to
talk
about
is
kind
of
yeah.
A
What
what
the
next,
when
the
next
network
upgrade,
will
be,
what
we
want
to
do
when
we
want
to
do
it
kind
of
for
the
first
time
since
maynet,
we
don't
have
anything
immediately
coming
down
the
pipeline,
which
is
nice,
and
I
think
it's
especially
good
for
right
now,
but
for
implementers
here
to
maybe
take
a
little
bit
of
time
so
to
like
flash
flush
out,
the
implementations
themselves
get
ready
to
productionize
without
the
imminent
network
upgrade
coming
down
so
yeah
inside
there.
A
A
So,
yes,
I
think
we'll
probably-
and
this
is
entirely
open
for
discussion,
but
I'm
thinking
we'll
have
one
upgrade
one
more
upgrade
in
this
year.
Probably
in
q3
as
well
as
our
q4
is
my
guess,
but
yeah
we
will
see
how
work
work
shapes
up
for
that
yeah.
Is
there
any
anything
that
people
have
thoughts
about
that
anything
that
people
are
imminently
looking
to
get
in
or
do
we
want
to
wait
longer?
C
C
Yeah,
that
is
one
thing
I
want
to
get
some
information,
how
yeah
the
quote:
developers.
G
C
Things
about
it
and
when
do
we
think
that
we
could
incorporate
it
in
in
a
system,
and
another
thing
is
that
I
will
think
about
the
yeah,
the
storage
and
the
table
market.
We
we
should
make
it
much
easier
for
people
to
access
the
token
storage
yeah
for
the
yeah.
This
real
data
user.
C
A
Yeah
agreed,
I
think
so,
there's
a
couple
things.
There
yeah
definitely
agree
that
there's
a
lot
of
work
to
be
done
kind
of
all
around
to
make
both
storage
and
retrieval
better,
easier,
more
reliable
on
file
coin
and
its
various
implementations.
A
lot
of
that
is,
of
course,
like
not
protocol
level
but
implementation
level.
A
So
it's
good
if
we
can
all
kind
of
focus
on
that
and
fully
including
lotus
there
to
kind
of
improve
to
improve
that
overall
process
also
agreed
about
yeah
having
having
kind
of
a
happier
plan
and
that's
sort
of
what
I
wanted
to
start
doing
today.
We
definitely
won't
be
hammering
out
all
the
details,
but
from
my
perspective
I
think,
there's
kind
of
three
large
like
cool
ideas,
for
if
our
imminent
improvements
that
we
can
make
to
the
firefight
protocol.
A
One
is
steven,
as
you
mentioned,
putting
a
vm
on
file
coin
and
then
so
we
can
have
user
defined
smart
contracts.
There's
a
fib.
I
don't
know
if
there's
a
fip
itself.
I
know
there's
a
fib
issue
discussing
that.
That's
been
open
for
a
few
months
now
and
that's
definitely
something
we
want
to
do
it's
on
it's
mostly
just
a
matter
of
when
and
which
vm
in
particular
like
what
essentially
there's
a
design
decision
to
be
made
there.
A
So
that's
one
that
I
think
we
can
talk
about
in
a
future
meeting,
there's
a
conversation
on
lightweight
sector
updates,
which
is
basically
trying
to
make
it
easier
to
upgrade
the
twitter
capacity
sectors
where
right
now
it
pretty
much
involves
resealing
the
entire
sector,
which
is
slow
and
expensive
and
kind
of
kills
the
incentive,
because
you
might
as
well
just
feel
a
new
sector
at
that
point.
So
there's
an
interesting
conversation
there,
except
17,
has
already
been
opened
about
that.
A
The
third
one
and
the
one
I
was
hoping
to
talk
about
today,
because
I
figured
we
could
like
stagger
these
so
like
staggered
these
across
the
codex
meeting.
So
we're
not
talking
about
too
much
at
once.
The
third
one-
and
it
is
a
good
jumping
off
point-
is
this
idea
that
we're
calling
synthetic
for
it
and
I'll?
Let
you
kind
of
introduce
it
and
motivate
the
idea
to
the
group.
K
Yeah,
let
me
I'll
quickly
share
the
screen
so
yeah
some
time
ago,
three
days
ago,
I've
opened
a
fib
issue
on
it.
It
will
be
coming
soon.
So,
in
short,
currently,
when
miners
are
sealing
ceiling
sectors,
they
need
to
store
between
after
they
create
the
replica.
So
when
they
are
done
with
ceiling,
and
now
they
are
waiting
on
the
protocol,
they
need
to
store
about
450
gigabytes
of
data
for
32
gigabytes
sector.
K
Of
course,
this
gets
worse
with
batching
and
aggregation
because
you
need
to
store
the
data
until
you
can
submit
commit,
aggregated
proof
of
replication,
so
commit
aggregate
and
synthetic
powerapp
is
a
response
to
that
issue,
trying
to
reduce
the
amount
of
storage
they
need
in
like
while
the
process
is
not
ongoing
to
onboard
the
sector,
ensure
the
protocol
works
by
reducing
the
number
so
as
part
of
the
commit
process,
miners
have
to
respond
to
interactive
challenges
that
challenge
them
on
some
part
parts
of
the
sector,
and
we
have
proof
supposed
to
relate
to
that.
K
The
short
idea
is
to
remove
that
amount
of
these
challenges
that
the
network
can
ask
for,
for
the
the
miner
miner
to
reduce
it
from
almost
uncountable,
which
is,
like
the
whole,
all
possible
challenges
in
the
sector
to
a
limited
number,
that's
feasible
and
smaller
to
store
separately.
So
currently
from
our
our
analysis,
and
it
depends
on
what
parameters
we
choose
because
there's
some
trade
there
are
some
traders
there
from
security
analysis.
We
could
reduce
amount
of
storage.
K
The
miner
needs
between
ceiling
and
committing
on
chain
from
20,
450
gigabytes.
To
so
450
gigabytes
is
the
whole
the
whole
sector
and
the
cache
slash
layers
data
to
about
26
gigabytes,
plus
whatever
they
will
store.
After
so
it
would
be
roughly
60
gigabytes
for
32
gigabyte
sectors,
which
is
amazing
reduction,
especially
that
of
miners
frequently
would
have
to
move.
K
So
one
like
it
increases
the
it
will.
It
will
increase
the
uptake
of
aggregation
for
onboarding
sectors,
because
it's
cheaper
for
miners
to
wait
for
the
sector
for
more
sector
to
aggregate,
because
data
are
not
storing
400
gigabytes
of
data
and
secondly,
it
reduces
the
like
marginal
cost
of
onboarding
storage,
especially
for
small
miners
who,
for
whom,
like
the
amount
of
fast
storage
to
compute,
the
replica
is
very
limited
and
it's
expensive.
K
So
this
allows
them
to
and
it's
it
enables
them
to
use
again
aggregation
mo
more
efficiently.
So
like
roughly.
This
is
also
graphed
by
nikola.
So
we
are
ceiling
we're
generating
the
future
replica.
Then
we
are
generating
system
synthetic
challenges
and
we
can
remove
the
whole
replica.
The
the
replica
layers,
keeping
only
the
replica
and
keep
the
generative
challenges,
then
we
pre-commit
us
today
and
then,
when
we
proof
commit,
we
select
out
of
those
challenges
which
we
are
looking
at
270
000
of
them.
K
We
are.
We
are
selecting
out
of
these
challenges,
which
we
pre-completed.
The
responses
for
yeah.
Another
option
is
increasing
slightly
gpu
costs
for
minor
and
slightly
verification
costs.
At
the
benefit
of
less
of
these
challenges
we
will
we
are.
We
are
still
evaluating
that
the
majority
of
the
changes
are
in
the
proofs
code,
so
I
think
it's
pretty
isolated
for
all
implementations
and
changes
in
actors
are
minimal.
It's
it's
support
for
another
version
of
proofs,
so
for
us,
it's
minimal
because
we've
done
it
in
the
past.
K
K
No,
it
doesn't
so
so
this
the
the
number
of
synthetic
challenges
is
was
was
determined
by
another
security
analysis,
standby
input
collapse,
where
we
assumed
that
miners
try
to
fake
the
storage
and
and
like
the
number,
is
chosen
as
such
that
if
for
an
attacker
capable
of
grinding
to
the
80
sector
to
the
power
of
80
sectors,
they
are
not
capable
to
grind
enough
advantage
to
decrease
the
security
by
one
bit
of
the
onboarding
storage.
So
it's
it
doesn't
downgrade
the
security
of
the
protocol.
K
Yeah,
I
I
I'm
not
sure
either
it's
it's
something
you
have
to
like.
K
You
have
to
think
of
so
like
we
came
up
with
this
during
the
process
of
design
like
we
had
so
nicola,
and
his
team
were
designing
no
like
they
were
focused
on
on
non
no
buffer
power
up,
which
is
essentially
what
this
is
power
app
without
holding
a
buffer
for
a
long
time
and
primary
solution.
K
For
for
a
long
time
we
were
looking
at
was
non-interactive
power
up
when
we
completely
removed
the
pre-commit
step,
and
the
miner
can
go
straight
from
some
from
ceiling
to
proof
commit,
but
this
incurs
8x
gpu
cost
and
a
8x
verification
cost
minus
aggregation,
because
aggregation
makes
it
cheaper,
but
like
8x,
gpu
cost
is
enormous
for
miners,
because
gpu
cost
is
currently
a
big
part
of
the
cost.
K
For
of
seeing
the
storage
and
yeah
and
some
thinking
inside
of
the
box,
not
wanting
atex
gpu
costs
led
to
this,
and
we
figure
it
out.
L
K
Yeah
making
sure
like
convincing
ourselves
that
that
this
is
secure
to
took
a
while,
but
because
from
the
surface,
if
you
look
at
it,
it
doesn't
seem
that
it
should
be
really
possible
and
initially
like.
We
hoped
for
way,
lower
number
of
synthetic
challenges,
but
yeah
security
says
it
has
to
be
higher.
So
it's
higher.
A
F
Well,
I
just
have
to
say
that's.
This
is
a
very
big
deal,
because
I
mean
one
one
you
know
issue
I
would
kind
of
have,
with
falcone,
being
a
potential
replacement
for,
say
cloud
storage.
Is
that
the
right
amplification
factor,
which
is
essentially
what
it
is
of
you
know
a
32
gigabytes
of
set
of
sector
data?
To
like
you
know
12x?
Is
I
mean
that
it's
it's
it's
not
ideal
right.
F
It's
it's
a
and
what's
what's
really
neat
is
that
this
could
be
a
a
game
changer,
for
you
know
the
viability
of
the
network
and
its
capability
to
grow.
One
question
I
have
is
for
miners
who
are
currently
you
know
committing
or
yeah
committing
capacity
with
with
current
sector
formats.
Will
they
be
able
to
migrate
their
current
sectors
into
a
synthetical
rep.
K
K
F
Well,
I
would
say,
like
the
the
the
major
like
generally,
that
that
that
kind
of
generation
happens
off
of
the
storage
miner
anyway,
right,
like
generally,
people
will
have
a
dedicated
machine
for
ceiling
detectors
and
that's
really
cool,
but
then
there's
also
the
scalability
of
the
actual.
You
know
data
exactly.
K
That's
yeah
exactly
exciting
to
see
so
regarding
your
question
about
migration,
yeah
like
I,
it
should
be
so
miners
will
at
some
point,
miners
will
just
have
to
switch
which
type
of
the
proof
they
create
for
porp,
but
or
all
the
sectors
stay
the
same
like
the
only
part
it
essentially
touches
on
proof
sites
site
is
how
we
generate
which
challenge
which
parts
of
the
sector
like
a
tree.
K
Would
he
challenge
so
currently
we
generate
it
by
just
hash,
hashing,
interactive,
randomness
and
like
iterating
on
the
number
and
we're
changing
the
scheme
to
be
so,
the
syntax
it's
synthetic,
because
we
synthetically
generate
many
like
the
270
000
challenges,
which
is
almost
the
same
thing
as
we
would
do
in
the
proof
commit
step
so,
but
we
only
do
180
challenges
today,
so
so
in
in
essence,
like
yeah
like
there,
it's
not
not
a
problem
to
for
miners
to
to
migrate
to
this
scheme
like
us
forward,
like
storage
miners
actors
on
like
existing
storage
is
the
same.
F
Okay,
so
just
to
be
clear:
if
a
miner
has
you
know
committed
several
hundreds
of
terabytes
of
sectors-
and
you
know
they
at
least
like
drives
worth,
and
they
have
a
certain
number
of
sectors,
would
they
be
able
to
increase
the
number
of
sectors
committed
to
the
network
by
a
factor
of
12
really
are.
J
You
sorry
I'm
there,
I
think
so,
and
you
don't.
I
need
to
say
something
because
I
think
there
is
a
misunderstanding
yeah
how
some
of
this
works
today
when
you
seal,
you
expand
your
32
gigabytes
into
11
times,
32
gigabytes
only
for
140
blocks.
Whenever
you
do
proof
commits,
then
you
can
delete
the
11
layers
so
what
we
the
the
real
change
here
like
when
you
say
when
I
hear
when
I
hear
we're
augmenting
space,
we're
not
augmenting
space.
You
start
with.
C
J
The
proof
commits
you
start
with
32
you
go
to
32
times
11
for
140
blocks.
Then
you
receive
a
challenge.
Then
you
remove
the
11
layers.
From
this
point
onwards,
you
only
store
32.
so
to
the
question
will
will
sectors
that
were
already
committed
to
benefit
from
this?
There
is
no
way
that
they
can
benefit,
because
you
already
have
deleted
the
11
layers.
F
K
J
Main
problem
that
we're
trying
to
solve-
I
don't
know
if
it's
clear,
is
that
miners
when
they
seal
today
they
must
keep
11x
for
140
blocks,
which
is
a
few
hours
which
means
that,
because
they
have
to
do
this,
they
have
to
do
a
huge
amount
of
extra
operations
like
knowing
how
to
move
data
from
memory
to
their
disk.
J
You
know
how
to
keep
their
disk
crown
and
the
the
onboarding
rate
is
limited
by
the
amount
of
buffer
that
they
have
for
this
amount
of
time,
so
they
have
to
buy
extra
ssds,
and
so
what
we
want,
we
won't
say
no
don't
buy
access.
Is
this?
Let's
just
make
sure
that
you
can
go
at
this
at
the
fastest
speed
that
you
can
go
now.
J
What
kuba
is
showing
here
is
that
we
can
instead
of
storing
500
gigabytes
or
something
you're,
storing
26.,
but
you
know,
okubo
is
also
showing
that,
by
by
doing
an
access
snap,
instead
of
storing
26,
that
you
can
store
just
8
gigabytes,
and
so
this
is
a.
This
is
overall,
very
promising.
A
K
How
so
like
the
primary
reason
this
came
up
is
the
adoption
of
aggregation
with
miners
right,
because
miners
currently
have
to
keep
those
400
gigabytes
from
the
momentary
seal.
So
the
moment
they
proof
commit
on
chain
roughly
in
the
case
that
proof
comment,
aggregate
fails
or
something
like
that.
They
want
to
keep
that
data,
and
we
know,
like
some
break
operations,
are,
for
example,
move
to
doing
a
for
proof,
commit
targets
per
day
or
something
like
that.
A
Cool
any
other
questions
or
thoughts.
C
Yeah-
and
I
said
yeah
this-
this
is
a
very
good
thing
and
yeah
I'm
thinking
of
as
a
minor.
You
talk
about,
for
example,
as
a
current.
Yes,
the
algorithm,
the
miners
will
optimize
their
hardware
configuration
right.
So
was
a
new
program
introduced
and-
and
actually
I
was
thinking
that
all
the
miners
were,
we
think
about
their
hardware
configuration.
C
So
I
wasn't
yeah
if
they're
asked
if
there
are
some
estimation
or
analysis
in
rms,
which
will
really
benefit
all
the
manners
to
yeah.
Think
about
this
in
advance
and
to
perhaps
opposite
the
next
generation
of
the
hardware,
configuration
or
yeah
will
be.
It
will
be
quite
different
than
the
people
are
using
right
now,
yeah.
This
is
yeah
just
a
and
a
reminder
about
this,
which
is
good
everything
yeah.
K
Yeah
just
to
connect
with
that,
like
the
the
synthetic
challenge
response
step
would
be
performed
most
likely
on
the
same
machines
that
perform
pre-commit,
one,
which
is
already
disputed,
cpu
intensive
and
probably
the
longest
step,
yeah
the
longest
step
in
the
generation
of
like
onboarding
a
sector.
K
So,
in
my
opinion,
I
I
have
to
run
some
closer
numbers
and
like
until
we
have
implementation.
There's
no
100
like.
I
cannot
give
you
an
exact
number,
but
roughly
the
change
change
in
the
minor
setup
for
this
should
be
minimal
because
rest
of
the
proof
like
rest
of
the
system
stays
exact.
The
same.
The
balance
doesn't
change
apart
from
adding
one
small
step
in
right
after
generating
the
replica,
so
pre-commit,
one
procurement
too,.
C
F
Regardless
this
could
help
a
lot
with,
in,
in
this
case,
speeding
up
bringing
storage
online
to
the
network
and
also
ceiling
sectors
when
when
they
get
when
when
they
need
to
be
sealed,
is
that
correct
it
like
increases
sort
of
like
the
capability
to
scale
the
storage
needed
for
this?
So
essentially
they
have
to
they.
They
need
less
hardware
for
it,
and
also
that
could
speed
up
like
things
online
with
current
hardware.
Currently,
there
yeah
cool.
A
Sounds
good
yeah
yeah,
certainly
at
the
very
least
looking
forward
to
the
fifth
to
come.
Well,
I'm
sure,
we'll
all
think
about
it
more.
I
feel
like
from
my
perspective.
It
seems
fairly
obvious.
I
think
mostly
people
will
want
to
see
the
security
analysis
and
be
kind
of
be
convinced
by
it.
I'm
sure
the
community
will
be
excited
because
it
seems
like
a
strict
improvement
from
every
every
perspective,
so
yeah
that
sounds
exciting
cool.
Any
other
questions.
A
All
right,
yeah,
so
kind
of
taking
a
step
back.
I
think
this
is
this
is
of
the
kind
of
proposals
of
major
improvement
proposals
that
we
have.
This
is
probably
the
smallest
of
them.
It's
the
easiest
to
deliver
it's
the
least
painful
for
the
various
implementations
to
consume.
So
I
think
the
next
network
upgrade
will
assuming
we
go
with
this
next
network
upgrade
will
probably
revolve
around
synthetic
pour
up.
A
Of
course,
there
are
other
proposals
nicola
and
chatflax
light.
Great
sector
updates
is
one
of
them
which
we'll
probably
talk
about
in
the
next
meeting
and
then,
of
course,
there's
a
five
point
vm
as
well,
which
which
is
kind
of
actively
which
everyone's
interested
in,
but
those
are
obviously
somewhat
larger
scale
ideas,
so
we'll
see
how
we
wind
up
scoping
things
based
on
where
the
various
implementations
are
and
how
everyone
feels,
but
yeah.
That's
that's,
exciting,
cool
anything
else
that
anyone
wanted
to
talk
about.
A
Sounds
good,
let's
grab
a
book
here
then
thanks.
Everyone.