►
From YouTube: Filecoin Core Devs #57
Description
#filecoin #web3 #nft
Recording for: https://github.com/filecoin-project/core-devs/issues/136
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
Follow Filecoin!
Website: https://bit.ly/3ndAg44
Twitter: https://bit.ly/3ObND0x
Slack: https://bit.ly/3HKfFy7
Blog: https://bit.ly/3HFZFNv
Reddit: https://bit.ly/39N4Jmv
Telegram: https://bit.ly/3bkP8Ly
Subscribe to our newsletter! https://bit.ly/3Oy8J9j
#filecoin #ipfs #libp2p #web3 #nft
A
B
B
Today
we
have
just
a
number
of
things
to
discuss.
It
was
tough
Gathering
the
agenda
for
this
month's
call,
but
here
we
are.
We
have
the
minor
protocol
change
dependencies,
I'm,
not
sure.
If
Alex
is
here
yet
he
is
supposed
to
take
that
discussion
and
then
shiam
would
help
us
walk
us
through
the
sector.
Terminations
discussions.
B
I
also
don't
know
if
our
free
is
here
today
just
to
discuss.
Envy
19,
celebrate
General
chit
chat
about
how
that
went,
and
you
know
anything
back
and
then
we
will
take
a
final
like
housekeeping
and
Q
a
and
hopefully
I
can
go
to
bed
all
right
without
further
Ado.
Let
me
just
double
check
that
Alex
is
in
here.
Alex.
Are
you
here,
I,
don't
think
so.
C
B
A
Much
yes,
yes,
I
can
so
basically
We've
started
a
discussion
on
the
you
know.
Recent
trends
that
we've
detected
with
Secretary
of
organizations
of
the
short
pldr
basically,
is
that
we've
seen
a
steady
increase
in
the
network
terminations.
Maybe
we
can
go
into
the
previous
figure
in
the
previous
slide
to
kind
of
like
show
this,
so
we've
basically
captured
some
historical
data
and
we
visualized
this
better
to
see.
You
know
how
this
trend
has
been
changing
over
time.
So
there
are
two
levels
in
which
we've
done
this.
A
The
first
one
is:
we've
looked
at
the
daily
fraction
of
raw
by
terminating,
as
well
as
the
raw
pack
power
itself
in
in
measured
in
pib,
and
what
we've
basically
noticed
is
the
months
between
July
2022
to
March
2023.
The
network
is
actually,
you
know,
recorded
higher
values
to
the
for
both
the
daily
fraction
of
raw
partner
terminating
as
well
as
the
robot
terminating
itself.
Then
you
know
the
past
year
and
a
half
and
what
we
kind
of
done
is
we've.
A
You
know
or
looked
at
the
Strand,
and
we
wanted
to
ask
ourselves
a
question
that
if
you
know
the
present
Network
conditions
continue
and
if
the,
if
we
just
simply
fit
this
trend
into
the
data,
what
what
can
we
expect
in
the
coming
months?
What
can
we
expect
in
terms
of
you
know
like
what
what
this
number
will
look
like
in
the
future
and
we've
also
obtained
some?
A
You
know
projections
to
support
this
answer
and
we
see
that
the
trend
is
is
kind
of
increasing
and
if,
if
things
continue
to,
you
know,
go
in
the
current
trajectory,
we
basically
expect
the
terminations
to
just
go
up
in
the
coming
months.
So
maybe
we
can
go
to
the
next
slide
again,
all
right
yeah.
So
basically,
the.
A
You
know
look
at
the
current
termination
fee
structure,
but
then
we
realized
that
this
continued
to
stay
the
same
even
after
the
maximum
sector.
Lifetime
was
kind
of
revised
and
even
after
we've
seen
a
large
number
of
sectors
if
maximum
graduation
one
year
at
1.5
year,
aren't
going
to
be
the
network.
So
the
next
steps
that
we
wanted
to
kind
of
prompt
this
discussion
is
to
number
one
discuss.
If
there
is
a
problem
to
solve.
Does
the
community
think
that
this
is
something
that
is
alarm?
A
Maintenance
is
something
that
we
want
to
devote
our
resources
to,
and
if
the
answer
is
yes,
the
next
steps
would
be
to
you
know,
discuss
possible
improvements
as
to
what
we
can
do
to
address.
You
know
an
issue,
so
this
is
keeping
that
in
mind.
We
started
a
GitHub
discussion
to
see.
If,
if
we
can,
you
know
get
some
consensus
as
a
community
as
to
the
relevance
of
this
problem
and
and
get
some
ideas
and
potential
improvements.
A
Maybe
we
can
go
to
the
next
slide
and
so
right
now
yeah
so
the
so.
We
were
really
happy
that
the
discussion
has
gained
a
lot
of
traction
and
there's
been
a
lot
of
activities
from
multiple
stakeholders
over
the
past
few
days.
So
some
of
the
recurrent
themes
in
in
the
discussion
and
some
of
the
you
know,
suggestions
that
were
put
forth
was
that
you
know
termination
fees
for
for
CC
sector
should
be
reduced,
and
this
would
potentially
have
an
increased
rate
of
onboarding.
A
A
Yeah
thanks
for
that
and
yeah
one
more
sort
of
idea
was
that
having
no
bias
in
termination
fees
at
a
sector
level
and
instead
of
maybe
introducing
you
know
the
fee
at
SP
level,
and-
and
you
know,
one
more
thing
that
stood
out
was
to
simplify
the
mechanism
in
which
the
fees
are
computed.
So
what
we've
noticed
that
most
of
the
comments
and
most
of
the
discussions
is
basically
you
know
based
on
hypothesis
and
what
would
happen
under
different
scenarios
and
yeah.
A
A
So
we
need
to
have
concrete
evidence
on
the
outcomes
of
these
what-if
scenarios
and
before
we
do
that,
you
know
the
the
the
discussion
is
still
going
to
completely.
You
know
be
hypothetical
and
we
won't
have
any.
You
know
concrete
grounds
to
navigate
the
discussion
further
and
develop
any
of
the
ideas
that
have
been
presented,
and
so
as
a
Next
Step,
the
crypto
econ
lab,
is
aiming
to.
A
You
know,
use
agent-based
models
as
a
way
to
do
this,
and
we
basically
want
to
use
these
models
to
assess
the
termination
fee
effect
on
on
that
stability
and
and
test
out.
Some
of
the
ideas
that
have
been
brought
up
in
the
discussion
itself
and
use
that,
as
as
a
guide
to
further
navigate
this
discussion
and
and
see
what
the
community
feels
about
this,
oh
I,
think
that's
pretty
much
all
I
have
prepared
for
today.
B
C
Some
of
the
problems
like
you
know,
question.
Is
there
a
concern
about
robustness
of
storage
due
to
terminations
in
the
network?
Right
now
is
this
100
cc
sectors
which
are
maybe
a
little
bit
more
fungible
or
are
there
deals
where
data
is
dropping
out
of
the
network
due
to
storage
due
determinations?
That's
more!
That's
more!
Concerning
that's
like
point
a
point:
B
is
raw
byte
power
or,
like
are
all
of
the
other
SPS
who
are
making
commitments
to
the
network.
C
We
want
everyone
to
be
incentive,
aligned
with
building
a
strong,
Network
together
and
so
I
think
that
would
be
a
question.
Is
there
a
good
incentive
throughout
the
life
cycle
of
both
a
cc,
or
you
know
a
deal
sector
to
that?
All
of
the
other
participants
that
your
incentive
aligned
with
strong,
robust,
like
commitment
to
the
network
and
making
the
network
stronger.
C
Even
if
you
get
out
the
network
is
still
stronger
because
of
that
and
and
I
guess,
I
completely
agree
with
you
as
we
start
having
longer
term
sectors
on
the
network,
it
might
be
like
there
might
be
literally
a
bug
here
where
our
our
termination
fee
literally
was
never
planned
around
having
more
than
one
and
a
half
year
sectors.
I
think
it's
like
not
super
robust
to
change.
You
know,
for
example,
when
there
was
all
of
the
you
know,
duration
multiplier
conversations
was
like
yep.
C
We're
gonna
definitely
need
to
proportionally
increase
our
termination
fee,
as
we
start
having
longer
term
deals,
because
there
is
increased
risk
there,
and
we
don't
want
people
who
are
going
to
be.
You
know
faking
that
longer
term
commitment
to
the
network
and
aren't
you
know
putting
up
resources
for
it,
and
so
I
guess
those
I
would
decompose
is
like
kind
of
three
separate
problems
that
do
all
have
inputs
into
what
would
be
the
right
termination
fee
structure,
but
right
now
I
like
if
we
don't
decompose
the
problems
and
be
like
great.
C
You
know
this
is
the
the
sub
problems
we're
trying
to
solve.
Then
it's
a
little
bit
like
hey.
We
project
and
I
think
it's
a
little
bit
fuzzy
these
projection
numbers
right
now,
because
from
what
I
see
like
there
is
an
increase,
but
it's
like
not
a
smooth
increase.
It's
like
choppy
and
sporadic,
and
it's
totally
based
on
Market
changes
and
like
I,
don't
know
how
much
I
believe
the
projection
honestly
like
because
I
think
it
takes
a
lot
of
variables
to
do
any
projection
like
this
accurately
I
think
likely.
C
There
will
be
increases
in
the
future,
because
economics
are
hard
right
now,
but
but
I
would
want
us
to
decompose
the
problems
such
that
we
design
a
good
solution
that
accounts
for
the
various
cell
problems.
So
that
would
be
like
my
my
feedback
over
the
top
I
would
also
probably
not
just
take
like
some
of
the
themes
in
current
discussions,
like
those
are
things
that
people
are
asking
for,
but
they
are
not
necessarily
good
things
that
align
with
you
know:
good
strong,
Network
overall,
for
example,
the
like
great
make
terminations
really
low.
C
A
Thank
you
so
much
for
that,
but
I
think
it's
already
useful.
So
in
terms
of
decomposing,
the
problem
I
think
that's
that's
pretty
much.
What
people
kind
of
feel
you
know
striving
to
do.
We've
been,
you
know,
doing
some
more
analysis
to
understand
about
how
many
of
these
terminations
are
through
CC
sectors
through
these
sectors
and
so
on,
and
with
regards
to
the
the
network
level
perspective.
A
That's
one
thing
that
we
haven't
looked
at
yet,
but
then
it
makes
it
totally
makes
a
lot
of
sense
to
do
that
and
and
that's
something
we
definitely
be
looking
to
yeah.
Thank
you
so
much
for
the
feedback
and
suggestion
we
will
definitely
look
to
incorporate
this
and-
and
hopefully
you
know,
guide
the
discussion
a
little
better
and
not
keep
it
as
opening
them.
D
Yes,
please
yeah
first
off.
Thank
you
very
much
Sean
for
for
presenting
this.
It
makes
me
very
I'm
very
glad
to
know
that
there
are
folks
and
teams
actively
monitoring
this
kind
of
thing,
because
I
know
that
I
personally,
and
perhaps
my
team
more
broadly,
aren't
paying
attention
to
these
things
as
much
but
they're,
obviously
very,
very
important.
So
thank
you,
yeah,
so
I
think
I
broadly
agree
with.
D
Basically
everything
Molly
said
to
her
last
Point
yeah
I
I
would
also
want
a
plus
one
that
yeah
some
of
the
ideas
that
will
arise
from
a
discussion
like
this
are
potentially
I
would
personally
describe
them
with
just
bad
ideas.
File
coin
by
definition,
is
not
a
network
that
we
want
people
to
be
hopping
on
and
off
every
time
as
they
believe
that
it's
not
the
point
of
file
coin,
and
if
that's
what
you
want
that,
that's
not
right
that
before
it
yeah.
D
The
thing
is
I
think
all
of
this
stuff
is
very,
very
complicated,
much
more
complicated
than
potentially
the
kind
of
core
engineering
side
of
things
that
I
that
a
lot
of
us
work
on
and
therefore
much
more
easier
to
get
wrong,
and
so
so
certainly
you
know
finicky
things
that
we
really
need
to
like
bet
every
idea
thoroughly
and
think
through
and
analyze,
which
I
feel
a
confidence.
It
will
do
to
the
to
the
kind
of
the
motivating
discussion.
D
I
have
a
a
couple
of
thoughts,
I
think
I,
I
agree
with
Molly
and
I.
Think
a
question
like
this
kind
of
gets
decomposed
along
a
few
different
taxis.
An
important
one
is
a
product
one
that
Molly
mentioned
a
second
one.
That
comes
to
mind,
so
me
is
kind
of
like
network
security
itself.
There
is
a
point
where,
if
sufficient
sectors
were
terminated,
filecoin
is
a
network
would
become
less
secure
in
that
it
would
be
easier
to
attack
by
some
bad
actor.
D
C
D
So
I
think
my
suggestion,
I
guess
I'd
say,
is
I.
Think
the
single
best
thing
we
can
do-
and
you
mentioned
that
you're
already
starting
to
do
this
or
already
doing
this-
is
try
to
find
in
the
sectors
that
are
being
terminated
at
Molly
pointed
out
it's
fairly
it's
you
know
it's
not
a
smooth
curve
or
some.
So
it's
a
little
a
little
Jagged,
but
I
would
be
interested
in
seeing
yeah
CT
sectors
versus
steel
sectors,
short-term
sector,
long-term
sectors.
D
The
other
question
is
when
these
sectors
were
committed,
my
I
I
always
have
a
hard
time
understanding
the
math
of
the
termination
penalty,
but
my
understanding
is
termination
penalties.
Poor
sectors
have
potentially
changed
over
time,
so
maybe
these
are
just
because
of
network
conditions.
Today
these
are
just
sectors
that
are,
it
is
rational
to
terminate,
but
if
new
sector,
if
the
majority
of
sectors
are
not
in
that
category,
then
potentially
we
have
less
of
a
problem.
D
I'm
widely
speculating
here,
I,
don't
actually
know
what
the
what
the
status
is,
but
yeah
I
do
think
that
kind
of
like
almost
yeah
pattern
detection
is
probably
in
my
opinion,
is
a
really
good
thing
to
do
here.
The
other
thing
that
I
don't
know
if
this
is
always
feasible
or
not,
but
actually
even
harder
to
do,
is
if
we
know
which
storage
providers
these
are
I
would
be
interested
in
just
kind
of
asking
them.
You
know.
D
Obviously
it's
totally
within
focuses
right
to
terminate
their
sectors,
but
I
would
be
interested
in
hearing
a
little
bit
more
about
why
they're
choosing
to
make
that
decision.
You
know
if
it's
just
crypto
economic
fact
or
just
economic
factors.
I
can
totally
understand
that,
but
if
there
is
something
that
we
can
kind
of
do
at
a
protocol
level
to
make
make
it
easier
for
them
to
stay,
because
that
will
likely
just
be
an
improvement
anyway,
then
that
could
be
an
interesting
impetus
for
us
to
just
improve
5.
more
generally
yeah.
D
C
I,
thank
you
for
that.
Last
idea.
Are
you
just
because
it
triggered
one
that
I've
been
having,
which
was
it
could
be
really
interesting
to
like,
especially
for
a
deal
sector
to
waive
the
termination
fee?
If
someone
else
kind
of
like
replicates,
if,
if
you,
if
you
are
able
to
pass
off
your
deal
to
some
other
storage
provider
such
that,
you
know
it's
like
great,
you
know.
C
I'm
things
are
hard
I'm
going
out
of
business
or
I'm
moving
to
some
other
area,
or
something
and
now
I
want
to
transfer
this
sector
to
someone
else
and
they're
going
to
keep
these
deals
going
and
then
now
I
get
to
waive
the
termination
fee
and
I
can
you
know,
hand
off
the
responsibility
to
some
other
storage
provider.
Who
can
continue
that
forward?
C
I,
don't
know,
that's,
maybe
a
question
it
may
or
may
not
actually
affect
termination
fee.
It
might
be
other
protocol
hooks
that
we
could
do
that.
Would
support
that
sort
of
movement
between
storage
providers,
but
in
a
landscape
where
we
might
see
some
amount
of
consolidation,
or
we
might
you
know,
expect
storage
providers
to
to
want
to
have
that
flexibility
of
like
great
ear.
You
know
you
know.
C
How
are
we
rebalancing
the
thing
that
Falcon
is
trying
to
do
within
this
ecosystem,
even
where
individuals
might
need
to
cycle
making
it
easy
for
that
cycling
to
happen
at
a
protocol
level
and
creating
an
incentive
for
us
to
maintain
good,
robust
storage,
even
as
individuals
might
shift
behind
the
scenes?
I.
Imagine
that
some
of
this
might
be
tricky
under
the
hood,
but
like
it
could
be
interesting
to
to
find
a
way
to
get
around
to
avoid
termination
fees
not
make
people
subject
to
termination
or
deal
related
deal
termination
fees.
D
B
E
Yeah,
thank
you
very
much
and
sorry.
I
missed
the
start
of
this
meeting.
I
just
took
a
break
at
the
wrong
time
and
missed
the
missed.
The
your
other
reminder
thanks.
This
is
gonna,
be
generally
brief.
I
have
been
working
on
trying
to
put
together
that
there's
a
bunch
of
different
ideas
that
been
many
of
these
have
been
floating
around
for
quite
some
time.
E
This
is
not.
This
is
not
a
most
of
these.
Don't
exist
in
the
in
the
sense
of
like
a
a
formal
FIP
specification,
because
some
of
them
have
flip
discussions.
Some
of
them
are
just
ideas
that
float
around
between
actor
developers
and
Lotus
team
and
encrypting
it
and
haven't
been
written
up
in
detail
yet,
but
but
it
does
form
these
these
things.
This
shows
us
two
different
charts
here.
There's
not
there's
not
there's
sort
of
a
fluke
that
it
shows
us
two
different
charts,
there's
one
set
that
depend
on
each
other.
E
E
E
On
the
right
hand,
side
of
this
chart
there's
a
set
of
changes
that
are
called
out
here
as
things
that
would
result
in
a
change
to
the
apis
that
a
minor
operator
interacts
with
when
they're
onboarding
storage,
and
so
the
main
point
of
calling
these
out
is
that
API
change
is
costly.
It's
it's.
It's
operational
cost
and
risk
for
for
nsps,
it's
work.
E
By
doing
this,
and
so
I
think
here
we
can,
we
can,
there
is
one
we
can
make
one
minor,
API
change,
that
that
would
support
the
future
implementation
of
any
of
those
things
that
are
pointing
at
it
in
in
the
chart,
although
of
course
it's
well
one
big
point
of
sort
of
doing
this
is
to
figure
out
if
there's
other
things.
This
is.
This
is
my
brain
dump.
E
If
there
are
other
changes
that
would
cause
minor
API
changes
or
other
protocol
changes
that
have
been
discussed,
that
I've
admitted
here
that
related
to
utility
that
might
have
some
dependency
relationship
on
these
other
ones
like
you
need
to
come
first
or
need
to
come
after
I.
Think
my
sort
of
biggest
request
here
is
to
help
surface
other
things
that
I
might
have
missed
in
this
chart,
so
that
we
can
have
this
this
idea
of
how
potential
improvements
relate
to
each
other,
which
you
inform
some
amount
of
sequencing.
E
B
E
D
Doing
this
I'm
sorry
I
just
want
to
say
thank
you
for
doing
this.
It's
definitely
useful.
I
have
not
been
paying
enough
attention
to
most
of
these
ideas
lately
to
I'm
going
to
take
them.
I
need
some
time
to
kind
of
grop
this
in
order
to
either
provide
feedback,
or
maybe
you
know
oh
yeah,
point
out
new
dependencies
or
challenge
any
of
the
existing
dependency
connections
here,
but
I
do
think
it's
useful
I
feel
like
for
me
personally.
D
The
biggest
question
mark
is
kind
of
what
you
said
about
prioritization
and
how
we,
as
file
coin
developers,
can
go
about
figuring
out
what
the
most
impactful
things
are.
But
that
is
a
much
harder
question
to
answer.
I'm,
not
sure
yeah
kind
of
what
our
path
of
attack
should
be
in
order
to
achieve
the
goals
that
we
explored
as
say,
we
have.
F
I
just
want
to
make
a
short
comment
that
I
think
this
view
is
actually
very,
very
helpful,
I
hear
about
these
ideas,
often
in
isolation
and
so
presenting
them
in
this
way.
It
makes
sense
to
me
and
is
helpful
to
me.
Alex
I
also
want
to
say
thanks
for
doing
the
whole
investigation
stuff
that
you
have
done
around
some
of
these
things
and
sharing
conversations
and
notes.
F
It's
been
very
helpful
to
get
additional
perspective
and
how
to
approach
some
of
this
stuff.
I
am
personally
very
interested
in
the
conversation
around
the
gasoline
stuff,
because
I
think
it
has
been
recently
brought
forward
as
a
pain
point
and
as
we
continue
to
explore
different
use
cases
on
the
network.
There
is
some
sense
in
thinking
about
how
we
want
to
ensure
that
resources
are
being
dedicated
in
a
fair
way
and
people
are
better
able
to
estimate
what
it
costs
to
do.
F
B
C
Yes
same
boat,
as
others
in
terms
of
needing
to
like
I
I,
find
this
view
very
useful,
but
I
think
I
might
find
it
a
little
like
the
data
that
I
feel
like
I'm
missing
in
connection
to
it
is
like
personally.
Half
of
these
words
don't
mean
anything
to
me
and
so
and
I.
Don't
know
why
pseudo
gasolines
or
something
like
you
know
what
motivates
each
of
these
different
things,
and
so
that
overlaying
of,
why
is
the
set
of
things
important
like
why?
C
Why
does
this
set
of
things
all
get
connected
to
each
other,
and
you
know
reasoning
through
like
okay,
well,
like
from
my
vantage
point
like
this
50
of
this
half
of
a
cycle
would
be
like
really
high
value,
and
that
implies
this
prerequisite.
So
like
okay,
that's
really
interesting,
but
I,
don't
know
quite
how
to
add
that
to
a
visualization
like
this,
unless
it
also
has
like
you
know
metadata
underneath
of
like
you
know,
tagline
this
unlocks.
C
You
know
this
this
valuable
thing
or
something
like
that,
but
that
personally
would
make
it
a
chunk
easier
for
me
to
parse
these
different
things,
as
it
is
I
feel
like
I'm
gonna
just
go
and
go
and
read
some
docs
and
hopefully
come
back
with
with
more
with
more
thoughts.
But
some
of
these
write-ups
are
pretty
pretty
chunky,
and
so,
like
the
more
that
we
can
bundle
down
and
tie
these
things
to
the
priorities
that
they
affect.
That
that'd
be
really
useful
as
well.
E
Yeah
sure,
thanks
I
hear
that
the
notion
page
linked
at
the
bottom
right
there
has
a
little
bit
more,
but
not
a
lot.
More
I
tried
to
I
train
intentionally
here,
not
to
do
my
usual
thing,
which
would
have
been
to
write
like
a
10-page
document
instead
of
doing
this
diagram.
So
that
does
mean
that
a
lot
of
the
details
are
missing
and
you
know
something
else:
yeah
I.
F
E
C
D
Yeah
I
think
Molly
brings
up
an
interesting
point.
This
was
a
great
high
level
view
and
for
a
lower
level
view
or
for
the
lowest
level
of
view.
You
could
you
know
all
of
the
individual,
so,
for
instance,
pseudo
gas,
Lanes
I
know
has
a
lot
of
conversations
have
already
happened
and
stuff
that's
been
written
down
for
that
more
intermediary
view.
That
explains
a
little
bit
more.
Why
we
might
want
one
of
some
of
these
things.
D
D
We
could
argue
each
of
these
individually
what
their
impact
would
have,
and
that
would
be
useful,
but
but
yeah
I
do
think
saying
having
a
separate
view
of
like
here
are
the
things
we
want
filecoin
to
achieve,
and
then
saying
this
leads
to
three
of
those
five
things.
They
certainly
do
any
of
them
at
all.
E
Yeah
I
think
very
on
board
with
that
a
challenge
here
that
makes
some
of
this
hard
I.
Think
generally,
is
that
there's
not
like
one
thing:
there's
not
like
one
clear
goal
or
one
clear
thing
at
the
end
of
a
dependency
chain
that
we're
trying
to
reach
this
thing
is
a
you
know
this
collection
of
small
things
which
all
together
add
up
to
a
much
more
capable
system,
but
it's
very
hard
to
put
one
is
like
the
as
the
end
point
or
the
motivating
reason
to
get
there.
E
This
is
you
know,
there's
no
Silver
Bullet,
there's
always
one
thing:
we're
going
for
that's
gonna
unlock
a
whole
lot
of
stuff
or
like
not
in
this
view,
right.
There
are
other
things
that
maybe
have
that
property
that
are
not
not
in
view
here,
but
that
does
make
it
hard.
It's
sort
of
it's
in
my
mind,
it's
sort
of
a
point
of
like
well.
G
Yeah
they're,
close
and
yeah
I
think
this
is
very
useful
and
I
really
like
this
is
to
simplify
the
yeah,
because
I
think
the
Falcon,
actually
they
yeah
design,
replacing,
are
kind
of
the
complex
Dynamic
and
storage
providers
and
also
the
ecosystem
participants
kind
of
hard
to
understand
the
the
whole
setting
I
wasn't
that
we
make
it
as
simple
is
you're
very
important
and
yeah.
This
is
one
thing
I
want
to
mention
here
and
also
here.
I
can
see
something
is.
G
Falcon
is
not
like
other
yeah
is
because
the
Falcon
used
to
take
a
lot
of
resource
and
or
bandwidth
to
do
their
storage
and
historical
verification
and
also
to
have
yeah
to
do
the
deal
the
deal
handling.
So
that
will
really
take
a
lot
of
bandwidth
of
network
so
yeah.
Well,
we
support
in
fbm
and
well.
We
support
a
lot
of
I
mean
yes,
but
contract
and
yeah.
G
A
network
actually
has
a
support
plan.
Yes,
book
time
is
actually
yeah
30
seconds,
which
is
kind
of
long.
We
want
to
Shorter
that
I
would
think
that
if
we
keep
and
keep
this
design,
it
will
be
very
hard
for
us
to
adopt
many
many
user
defined
hackers
and
to
support
High
TPS
and
also,
at
the
same
time,
to
support
a
lot
of
storage
and
and
a
lot
of
deals.
So
we
need
to
think
about
some
other
things
yeah,
for
example,
yeah.
C
G
D
Sorry
I
didn't
forget
to
lower
that.
Okay,
given
that
I
am
muted,
I
would
say,
I
think
Steven.
Ray
is
a
very
good
point.
I'll
just
quickly
add
Falcon
is
also
unique
in
that
we
do
have
a
message
that
needs
to
land
on
chain
like
a
transaction
that
has
to
land
our
submit
window
post
messages,
whether
you
like
it
or
not.
So
that's
another.
You
can
choose
to
send
it
at
some
other
time.
That's
not
a
it's!
Not
it's
a
non!
D
B
D
D
This
was
a
trend
that
we
observed.
You
know
a
few
months
ago
opened
a
flip
that
investigated
team
of
the
solution
opened
effect
that
would
address
it
as
well
as
more
longer
term
Solutions
and
basically
said
I
think
we
think
we're
catching
this
at
a
good
time,
but
it
has
the
potential
to
cause
major
problems.
Thankfully
you
did
not
cause
major
problems,
but
it
did
start
to
cause
problems
to
the
network,
somewhat
compounding
with
the
effect
of
increased
activity
as
a
result
of
the
logical
settlements.
D
So
at
the
start
of
so
we
knew
we
knew.
That
would
be
the
case,
and
so
we
wanted
to
have
an
upgrade
sooner
than
we
were
initially
thinking
six
weeks
after
depend
from
one
period
and
and
so
we're
moving
ahead
with
that.
But
at
the
start
of
April
we
did
start
to
note
notice
a
significant
decrease
in
the
number
of
blocks
per
chipset
than
the
total
wind
cap.
D
The
average
win
count,
and
as
a
result
of
that
several
important
chain,
metrics
decreased,
the
revenue
for
storage
providers
went
down
overall
change,
throughput
went
down
and
in
general
the
network
was
left
healthy.
It
was
fourth
year
stability
went
down
as
a
result
of
that
no
RPC
service
providers
reported
issues
as
well.
So
all
of
that
motivated
this
upgrade
and
at
some
point
we
made
the
sort
of
a
difficult
call
to
expedite
the
the
time
that
this
would
go,
live
on,
mainnet
and
and
yeah.
D
This
was
not
a
perfect
upgrade
and
and
after
you
in
particular,
but
I'm
sure
we're
all
aware
that
there
were
issues
we
did
deploy
buggy
code
to
our
calibration
test,
Network,
which
we
never
want
to
do.
We
were
able
to
kind
of
touch
it,
but
there
was
certainly
a
cost
there.
There
was
also
just
a
cost
in
the
quick
turnaround
time
from
our
various
integration
partners
and
so
on
and
I
do
think.
This
is
a
really
good
opportunity
to
retro
because
of
how
we
as
core
devs
operate.
D
Part
of
that
is
how
could
we
have
no
notice
this
problem
sooner.
This
was
not
a
problem
that
sprung
up
on
us.
So
what
can
we
put
in
place
to
make
sure
that
the
next
time
we
say
it's
a
similar
problem,
because
we
absolutely
will
save
more
challenges
like
this
in
the
future?
How
we're
aware
of
it
sooner
and
have
these
Solutions
in
place
quicker,
but
also
how?
D
We
made
decisions
quickly
and
I'm
grateful
to
everyone
that
we're
able
to
move
at
that
pace,
but
we
probably
did
not
get
everyone's
opinion
as
much
as
we
should
have,
especially
with
decisions
like
how
to
act,
whether
we
should
be
exploiting
the
upgrade,
how
to
save
the
calibration
test,
Network
and
so
on
and
I
think
I
think
we
will
have
to
continue
to
move
quickly
in
the
future.
So
the
answer
is
not
going
to
be
as
simple
as
just
take
more
time.
D
Just
take
a
week
to
deliberate,
but
I
also
would
hope
yeah,
but
I
would
like
a
better
answer.
Then
you
know
make
a
tough
call
and
hope
that
it
works
out
for
everyone,
but
if
I
think
I'm
really
looking
forward
to
a
retrospective
on
this
overall
Network
upgrade
I.
Think
I
would
very
much
like
to
have
one
in
the
next
four
devs
call.
I
really
want
to
hear
your
thoughts
from,
in
particular,
the
Venus
and
the
forest
teams,
but
also
if
we
could
collect
Arts
from
the
community.
D
I
think
that
would
be
great,
so
I
I'm
excited
to
kind
of
look
back
at
this
upgrade,
but
for
now,
I'm
very
pleased
to
say
that
the
upgrade
succeeded
on
mainnet,
in
addition
to
the
faster
black
validation
time
that
I
mentioned.
It
also
made
our
winter
post
more
secure
through
flip61,
which
is
another
major
win,
and
the
feedback
that
we've
received
for
a
kind
of
across
the
board
has
been
really
really
good
search
providers
that
were
reporting
major
revenue
losses
are
through
essentially
said.
D
All
the
problems
went
away,
24
hours
after
the
upgrade,
and
it
really
trickles
down
from
there
all
the
way
to
all
across
the
community.
I
should
say
to
like
hackathons
where
things
are
participating
more
things
that
are
running
more
reliably
to
yeah.
Seven
folks,
who
are
kind
of
working
with
service,
provide
RPC
service
providers,
who
reported
their
latencies
dropped
like
that
and
so
on.
So
I
think.
Overall.
This
is
a
really
good
win
for
final
point.
D
My
personally,
my
note
is
a
lot
more
stable
now
and
I'm
grateful
for
that
and
I
don't
even
run
a
minor
or
anything
critical
like
that
so
yeah.
Thank
you.
Everyone
who
worked
on
this,
who
identified
the
problem
made
tough
calls
worked
quickly
to
make
it
all
happen
and
I
look
forward
to
looking
back
at
the
process
more
comprehensively
and
identifying
what
we
can
do
better.
The
next
time,
yeah
I
think
that's
all
I
have
to
say,
but
I'm
very
interested
in
hearing
other
people's
perspectives.
B
C
Thanks
yeah
Stephen,
as,
as
you
know,
one
of
the
other
implementation
leads
on
the
call.
I'd
love
your
your
perspective
as
well
on
like
what
went
well,
what
didn't
go
out.
I
know
we'll
probably
do
more
of
a
retro
later
but,
like
you
know
from
from
my
vantage
points,
at
least
like
you
know,
this
came
from
you
know
a
number
of
folks
vocalizing,
like
oh
I,
don't
know
if
we're
gonna
make
it
to
this
upgrade.
C
Okay,
everyone,
okay,
thanks,
bye,
it's
happening,
and
it
went
a
little
bit
fast
from
a
in
terms
of
like
okay,
we
think
there's
an
upcoming
potential,
significant
negative
impact
on
the
entire
Community.
All
of
our
RPC
providers
are
in
pain,
storage
providers
are
experiencing
lower,
win
counts
like
we
are
in
a
bad,
unhealthy,
State.
C
We
are
concerned,
it
might
get
even
more
unhealthy,
let's,
let's
accelerate
getting
out
of
this
state,
whereas
I
think
the
way
that
the
conversation
like,
for
example,
the
like
Thread
about
it
in
core
devs,
was
a
little
bit
more.
Like
hey,
we
looked
at
the
things
and
we
think
we
need
to
do
this.
Okay,
this
is
happening
versus,
like
you
know,
Stephen
David
Henderson,
like
other
folks,
like
you
know,
we
think
there's
a
significant.
It's
you
know
challenge
here.
C
Like
you
know
a
can.
Can
you
participate
in
this
upgrade?
We
think
that
these
are
going
to
be
the
downsides
of
accelerating
a
release
where,
like
yes,
this
is
going
to
be
painful
for
node
operators,
because
we're
gonna
have
to
accelerate
our
timelines.
This
is
going
to
be
painful
for
exchanges
who
have
you
know
desire
longer,
inter
integration
time
frames,
but
like
here's,
here's
the
pros
and
cons
generally
I
find
the
more
concrete
we
can
be
and
open
about
hero,
pros
and
cons
on
both
sides
of
a
decision.
C
The
easier
it
is
for
us
all
to
you
know
be
be
a
part
of
that
decision.
Understand
why?
Why
we're
making
it
a
certain
way
and
feel
like
included
in
the
thought,
process
and
I,
think
we
we
didn't
do
as
good
of
a
job
as
I
think
we
we
could
in
doing
that
together
as
a
network.
So
that's
my
reflection,
but
Steven
I'd
love
your
thoughts.
B
D
B
D
And
I
I
do
think
that
kind
of
the
lotus
team
didn't
do
the
best
job
of
externalizing,
the
feedback
that
we
were
getting
from
our
users,
because
it
was
pretty
strong
who
pretty
strongly
worded
and
pretty
severe
and
and
I
do
think.
That's
something
that
we
can
do
better
the
next
time
as
opposed
to
hey
here's
our
proposal.
Does
it
work
thumbs
up
thumbs
down?
You
have
a
short
amount
of
time
to
make
a
decision,
because
it's
obviously
modernized
too
complicated
than
that.
D
D
The
critical
bug
that
kind
of
the
the
that
was
deployed
on
calibration
that
was
observed
by
I,
think
the
Venus
team
doing
some
testing
and
the
broader
Community
kind
of
swarmed
on
it
investigated
it
had
a
fix
and
so
on,
and
that
was
incredibly
valuable,
we'll
be
in
a
much
worse
place.
If
that
did
not
happen
and
I'm
very,
very
happy
about
that.
D
It
is
great
to
got
to
share
that
responsibility
across
the
community,
as
you
would
want
in
a
decentralized
ecosystem
like
we
have
and
as
part
of
the
Retro.
You
know
it's
obviously
bad
that
we
deployed
this
code
on
calibration
then
so
part
of
the
Retro
will
be.
Why
did
that
happen
in
the
first
place?
But
I
also
want
to
Retro
how
we
can
build
that
even
more
keep
this
momentum
going,
because
that
is
how
we'll
keep
file
coins
secure.
Moving
forward.
B
Great
job
Phoenix,
thank
you,
so
much
yeah
I
think
just
to
wrap
it
up.
Thank
you
so
much
everyone
for
joining
our
call.
Remember
we
also
have
started
Community
governance.
Calls.
If
you
have
not
registered
I,
will
share
the
link
around
it's,
not
a
technical.
You
know
Gathering,
it's
just
to
talk
about
governance
and
how
we
can
improve.
You
know
governing
our
ever
growing
protocol
and
then
obviously,
if
you
have
additional
thoughts,
comments,
suggestions
always
feel
free
to
Ping,
myself
and
or
Caitlin,
but
obviously
register
to
attend.
B
The
cgc
above
I
am
beginning
to
work
on
like
a
a
road
map
for
sort
of
like
governance
for
the
network,
and
if
you
have
like
projects
you're
working
on
or
fips
you're
hoping
to
land,
please
feel
free
to
flag
them
on
time
so
that
you
know
I
can
sort
of
put
that
into
perspective
of
this
Lino
rush.
But
thank
you
all
so
much
for
everyone
who
flagged
the
ideas
and
other
projects
they're
working
on.
That's
really
helpful.