►
From YouTube: Core Devs 53
Description
Recording for: https://github.com/filecoin-project/tpm/issues/124
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
A
Thank
you
all
for
joining
us.
This
is
filecoin
quartets
number
53..
Today
in
the
Western
Hemisphere,
it
is
Thursday
the
5th
of
January
elsewhere.
It
is
Friday.
The
6th
I
expect
we're
going
to
have
quite
a
bit
of
conversation
today,
specifically
around
the
file
Quinn
Network
18,
upgrade,
and
also
the
sector
duration
multiplier.
Fifth,
draft
that
this
crypto
econ
lab
team
has
been
so
diligently
working
on
and
as
always
at
the
end
plenty
of
time
for
Q
a.
If
there's
any
walk-on
topics
that
anyone
would
like
to
propose.
B
Thanks
hi
everyone.
Can
you
hear
me
Caitlyn.
B
Great
okay,
perfect
yeah,
so
this
one
will
just
be
about
the
SCM
fit,
which
I'm
sure
many
of
us
are
familiar
with.
We
put
in
a
new
draft
a
couple
weeks
ago
and
then
recently,
crypto
econ
lab,
followed
up
with
some
analysis
and
modeling.
Regarding
the
the
question
of
whether
or
not
it
should
apply
to
all
sectors
or
only
fully
onboarded
sectors.
B
This
was
posted
by
Tom.
You
know
a
couple
days
ago,
I
think
the
goal
here
should
be
to
have
an
open
discussion
with
core
devs
about
number
one,
on
landing
on
the
importance
of
this
being
implemented
in
nv18,
which
is
between
March,
1st
and
March
15th,
and
then
the
second
question
is
specifically
how
we
feel
about
which
version
of
the
policy
kind
of
enters.
B
The
network
I
think
there's
broad
alignment
that
some
version
of
the
SDM,
whether
that
be
all
sectors
or
just
newly
onboarded
sectors,
or
some
kind
of
caveat
of
those
to
like
kind
of
combinations,
is
better
for
the
network.
Overall,
given
the
current,
you
know,
macroeconomic
conditions,
which
crypto
econ
lab,
has
talked
about
kind
of
at
length.
So
this
one
here
is
what
is
the?
What
is
a,
what
is
the
best
way
to
move
forward
regarding
these?
B
Like
small
policy,
you
know
kind
of
nuances
to
the
FIP,
knowing
that
it
is
probably
beneficial
that
some
version
of
the
SCM
tip
lands
sooner
rather
than
later
in
the
network
sooner
being
nv18
in
in
early
March
with
that
I
think.
Maybe
this
is
a
good
time.
B
Just
you
know
have
an
open
discussion
if
people
have
thoughts
on
this
kind
of
parameter
or
policy
policy
question,
but
if
anyone
has
any
questions
regarding
the
FIB
itself
or
wants
to
take
a
step
back,
I'm
also,
you
know
misiacs,
Tom
and
Dave
I
think
are
here
and
Karen
as
well.
So
we
can
answer
some
of
those
questions.
B
Oh
I,
I
guess
one
last
thing
to
add
at
a
higher
level
is
if
it,
when
it
comes
to
from
from
like
a
Network
Health
perspective
from
the
perspective
of
encouraging
capacity,
not
just
onboarding,
but
retention,
crypto
econ
lab
would
advocate
for
a
version
of
the
policy
entering
a
network
where
this
applies
for
all
sectors,
meaning
that,
if
you
know
SPS,
can
extend
sectors
and
receive
a
SCM,
they
don't
have
to
you
know
kind
of
reseal
the
sector
in
order
to
to
receive
the
multiplier
when
it's
when
it's
onboarded.
B
B
B
You
know,
even
even
so
when
I
say
all
sectors,
I
mean
extended
sectors
as
well
as
newly
onboarded
ones,
rather
than
the
policy
only
of
only
applying
to
newly
onboarded
sectors.
So
if
you're
an
SD
and
once
you
extend
and
receive
a
sector
duration
multiplier,
you
can
do
so
without
having
to
recommit
a
sector
to
do
in
order
to
to
gain
that
qap
multiplier.
So
yeah
that
yeah.
That's
it.
D
I
have
a
question
for
Jenny
I
feel
like
you
made
a
comment
in
December,
but
what's
the
level
of
effort
associated.
E
With
applying
it
to
all
sectors,
and
is
that
feasible
in
the
shorter
term,.
F
Possible
to
do
that,
so
thank
you
for
the
for
the
update,
I
feel
like.
Maybe
we
can
it's
actually
like
really
good.
It's
good.
If
we
can
just
like
jump
into
my
session,
which
is
gonna
need
a
discussion
on
like
the
finding
the
scope
of
like
18,
which
we
can
further
discuss,
whether
we
should
include
the
SDM
in
this
upgrade
or
not
and
like,
if
so,
which
option
which
we
should
do.
How
does
that
sound.
B
D
I
just
want
to
make
sure
to
say
thank
you
for
the
people
doing
the
analysis
on
this
discussion
or
the
you
know
the
the
policy
decision
between
new
sectors
versus
all
sectors.
It's
you
know
much
more
comforting
to
like
try
to
make
this
decision
understanding
what
you
know
and
I
understand.
There's
a
modeled
impacts,
we're
not
predicting
the
future
here,
but
you
know
these
are
projections
about
what
would
happen
under
certain
assumptions,
but
it's
much
better
to
be
making
these
kind
of
decisions.
D
Having
done
that
thought
and
modeling
imperfect
as
it
is
so
I
want
to
say.
Thank
you
very
much
for
doing
that.
Yeah.
B
Also
Tom
and
Karen-
really,
you
know,
did
a
lot
there
as
well,
so
it
was
it's
really
good
to
have
to
have
that.
It's
also,
you
know
to
answer
that
question,
but
yeah
CEO
thanks,
you
Alex.
F
Okay,
maybe
I
can
give
some
like
a
quick
early,
18
updates.
Since
everyone
had
a.
Hopefully,
everyone
had
a
relaxing
like
holiday.
We
did
do
some
work,
so
I
have
some
like
updates
for
everyone
and
next
slide
so
quickly
on
my
agenda
like
on
this
topic
today,
others
have
the
updates.
I'm
gonna,
give
an
engineer
and
a
governance
update.
F
F
So
right
before,
like
we
go
to
the
holidays,
we
have
locked
down
the
sculpt
consideration
of
this
upgrade.
So
there
are
all
the
fifths
that
was
proposed
to
be
considered
included.
Sev
benefit,
that's
fevm,
related
547,
polar
security
effect,
which
was
accepted
already
a
fit
42
which
increased
a
Max
sector,
duration,
commitment,
I
believe
to
3.5
years
or
like
five
years,
but
that's
a
single
single
parameter
change
and
also,
of
course,
SPM
since
then
was
in
the
court.
F
F
That's
only
about
fevm
but
like
since
then
febm
team
has
been
writing
a
lot
of
the
fifths
and
doing
a
lot
of
engineering
development
and
after
coming
back
from
the
holiday
when
we
re-analysis
the
critic
of
the
progress
and
also
all
the
timeline
dependency,
we
realized
that
we
are
slightly
behind
on
the
fifth
writing,
because
the
guest
benchmarking
is
taking
longer
than
expected,
and
the
team
needs
more
time
so
that
we
make
the
right
choices
on
the
fevm
guesses.
F
With
that
being
said,
because
of
because
of
the
engineering
work
needed
there,
we
can
not
have
a
fib
going
through
the
governance
process
without
the
final
guesses
and
given
that
the
process
also
have
a
very
strict,
you
know,
reveal
timeline,
and
that
adds
on
some
like
delay
in
the
February
timeline.
We
are
also
like
special
call
out.
We
are
also
constrainted
constrained.
There
are
special
consideration
is
that
on
the
Chinese
New
Year
is
January
from
the
January
22nd
to
the
January
31st.
We
will
have
the
whole
Venus
up.
F
If
you
enjoy
their
holiday
with
the
families
we
are,
we
are
also
going
to
have
the
Chinese
Community
out
of
office
during
that
period.
What
does
that
mean
is
that
we
cannot
perform
any
calibration
upgrades
during
that
period
because,
like
the
a
huge
amount
of
the
Community
member
will
be
out
and
one
of
the
core
implementation
team
will
be
out
of
office
all
that
being
said,
so
for
all
the
detailed
timelines
tasks
breakdowns.
F
You
can
find
find
on
this
page
that
I
link
in
the
zone
chat
which
I
we
can
share
with
the
public
Community
after
this
call
as
well.
So
with
everything
being
said,
assuming
we
are
still
remaining
the
discuss
scope
to
only
have
fev-m-e-n-v-80
the
new
projected
timeline
is
we
can
kick
off.
The
hyperspace,
which
is
the
newly
launched
developer,
focused
Perpetual,
test
net
on
January,
the
16th.
We
will
kick
off
a
space
War
Paxon
for
febm
from
January
20th
to
February
the
10th.
F
We're
gonna
have
a
calibration
upgrade
on
February
the
6th
and
to
introduce
at
the
evm
and,
most
importantly,
we
are
gonna
launch
at
the
ebm
to
the
following
minute
by
March
the
first
again,
all
these
timeline
are
our
targeted
timeline
and
is
subject
to
change
according
to
development,
audit
and
governance
process.
Any
questions
so
far.
F
Next
slide,
so
that's
always
saying
we
have
again
before
the
holiday.
F
So
what
happened
during
the
holiday
people
were
actually
like
doing
work
which,
including
thanks
to
the
CEO,
they
have
been
doing
more
analysis
and
compared
between
the
four
options
that
they
proposed
for
SDM,
and
we
have
more
information
that,
like,
like
just
said,
they
have
data
to
show
that
if
SDM
can
be
applied
to
all
the
sectors,
it
is
more
beneficial
for
the
network
than
only
apply
SDM
to
the
new
sectors,
which
is
like
a
new
information
that
we
have
because,
like
the
current
proposed
like
fit
draft
only
including
and
to
the
to
to
the
new
sectors,
another
piece
of
new
information
again
is
like
the
updated
febm
timeline.
F
One
of
the
core
reasons
that
we
were
not
considering
STM
is
because
of
the
engineering
resource
constraint
and
the
very
ambitious
like
timeline.
So
we
said
if
we
are
aiming
for
a
February
launch
for
febm,
yet
it
is
almost
impossible
to
get
from
an
engineering
resource
perspective.
It's
almost
impossible
to
also
include
sdn
and
the
potentially
fit
47
and
there's
some
like
necessary
bug.
Fixes.
F
Now
again,
that's
changed.
So
given,
given
the
new
timeline,
information
of
what
I
am
hoping
of
to
do
today
is
like
to
reach
consensus
on
the
final
scope,
especially
on
whether
we
should
be
including
SDM
or
not
in
this
call
and
with
the
final
scope
defined
on
the
core.
That
I've
sure
commit
to
your
timeline
for
the
upgrade
for
the
sake
of
community
as
well,
because
a
lot
of
people
are
waiting
for
the
Feb
and
launch.
So
that's
our
goal
today,
so
jumping
into
how
we
can
slowly
move
into
consensus.
F
So
so
everyone's
probably
has
so
like
yesterday,
I
had
posted
this,
like
decision
Matrix,
to
compare
the
options
that
we
have.
So
there
are
like
eight
options
there.
I
know
it
was
a
lot
but
like
on
High
level,
we
can
categorize
them
into
that's
like
the
following.
First
is
like
don't
change
the
scope
only
do
fevm.
We
have
been
planning
febm
for
the
past
eight
months
now,
I
would
say:
I
had
been
long
time
cooking
a
lot
of
like
Community.
F
Every
ecosystem
effort
has
been
building
around
like
fevm
our
very
like
initial
timeline
of
One
Tree
fev
and
was
actually
kind
of
like
late
Q4
in
2022,
so
like
according
to
that
timeline,
where
kind
of
you
know
slightly
behind
already
so,
like
you
know,
if
we
do
want
to
launch
like
fevm
like
summer
writer,
senator
for
all
the
amazing
ecosystem
benefits
and
networks
like
Improvement
that,
like
we
are
expecting,
we
we
should
stay
just
every.
F
Only
however
I
see
how,
as
like
Stefan,
has
like
posted
a
discussion
in
the
community
like
Forum
such
as
team.
There
are
a
couple
of
challenges.
The
network
is
facing,
including
micro
economy
started
storage
provider
like
growth
and
their
business,
and
all
those
reasons
we
probably
should
take
some
actions
to
to
support
our
community
to
maintain
healthy,
like
Network
status,
while
the
solution
being
proposed
again
right
now
is
SDM.
F
So
how
urgent
are
those
problems
and
can
SDM
be
one
of
the
solution
that
you
know
immediately
mitigates
some
of
the
problem
right
now,
it's
possible!
That's
why
we,
maybe
we
should
consider
including
an
SDM
along
with
fbvm
and
and
the
other
thing
we
should
consider,
is
like
SDM
will
like
extend
the
sector
duration
into
five
years.
Then
there
remain
risk
of
power
up
security
concern
then
do
we
want
to
launch?
Should
we
like
avoid
that
by
implementing
step
47
so
that
that's
all
the
all
the
options
that
we
have?
F
Oh
of
course
there's
another
one
that
Nick
already
mentioned.
If
we
include
SPM,
should
we
apply
to
all
the
sectors
or
only
new,
newly
onboarded
sectors,
so
I
think,
like
everyone
here,
probably
has
to
read
all
the
operations
and
like
potential
trade-offs.
So
what
I'm
gonna
do
next
is
I'm
gonna
propose
what
get
Gathering
all
the
information
I
have
been
working
on
engaging
in
this
for
the
past
months.
F
F
So,
as
the
network
upgrade
coordinator
just
like
for
this
one,
taking
in
all
the
feedbacks,
I
am
personally
not
personally
sorry
as
the
Lord,
also
like
with
the
input
from
the
heavily
from
the
Lotus
team,
we
are
proposing
that
we
should
only
include
febm
and
commit
to
a
March
1st,
upgrade
main
reason
being
again.
Febm
has
been
one
of
the
top
priority
for
the
network,
defined
as
above
the
top
priority
for
the
network
since
last
June.
F
We
have
been
working
on
that
for
eight
months
and
it
is
important
for
us
to
ship
that
not
only
just
for
for
the
protocol,
but
also
for
our
community
and
a
lot
of
like
business
that
is
building
on
top
of
fem
to
to
have
that
feature
launched
in
the
network.
Only
shipping,
if
evm
also
means
we
will
have
a
super
light
migration
across
like
upon
upon
the
upgrade.
We
have
analysis,
the
the
implementation
of
SDM,
no
matter
which
option
we
go
with
SDM
migration,
a
sector
info
migration
is
absolutely
needed.
F
We
recently
has
like
went
through
our
sector
info
migration
in
the
last
upgrade
and
the
shark
thing,
and
it
was.
It
was
not
too
bad,
but
it
was
quite
challenging
for
some
node
operators
because
upon
my
heavy
migration,
the
the
manner
and
the
memory
usage
on
the
Node
is
like
higher
and
it
adds
risk
for
the
null
operators
node
to
to
to
go
out
of
sync
with
the
network.
F
So
so
in
the
last
upgrade
we
have
exchanges
like
coinbase
and
also
our
main
service
API
service
provider
like
glyph
all
their
like
some
decks.
All
their
notes
had
challenges
of
like
going
through
the
migration
and
keep
in
sync
with
the
network.
We
from
my
perspective
we
for
the
fevm
launch.
It
is
one
of
the
most
important
upgrade
that
so
far
like
six
minutes
that
we
are
trying
to
do
so
like
if
we
can
avoid
any
additional
draw
out
risk.
F
That
would
be
amazing.
That's
why,
like
any
solution
that
can
avoid
a
migration,
is,
is
what's
like
in
favor
here
and
also
last
but
not
least,
yes,
that
to
to
implement
like
SDM
or
anything,
that's
needed
for
supporting
SDM,
because
we
haven't
done
any
engineering
workout
yet
so
there
are
potentially
unforeseen
like
challenges
on
the
implementation,
and
we
probably
need
to
spend
more
time
and
to
to
to
to
work
on
Lotus
to
make
the
migration
a
risk
slower
in
support
the
successful
like
fevm
launch.
F
So
that
adds
more
risk
onto
the
upgrade
like
timeline
and
again,
like
with
everything
being
said,
to
make
sure
we
can
launch
fevm
sooner
rather
than
later.
We
are
proposing
to
only
include
fevm
in
this
upgrade.
F
D
It's
a
hard
decision.
I
think
there
are
multiple
options
that
would
be
sort
of
acceptable
and
hard
very
hard
ahead
of
time
to
understand
which
one
is
like
you
know,
strictly
Superior,
but
if
we
go
this
way
of
scoping
down
the
the
upgrades
to
be
strictly
the
fdm
in
order
to
give
us
maximum
certainty
and
lowest
risk
for
that
that
I,
you
know,
would,
as
I
have
before,
urge
that
we
need
to
turn
around
another
Network
upgrade
after
that
as
soon
as
possible.
D
H
Yeah
I
mean
I
was
just
going
to
say
something
I
would
be
slightly
worried
about,
is
that
the
dead
has
slipped
already
a
little
bit
for
fem,
that's
being
pushed
forward,
I
mean
it
could
be
pushed
forward
again,
and
this
is
all
more
time
during
which
some
of
the
issues
that
the
secretary's
multiplier
proposal
is
trying
to
address.
These
may
not
get
better
by
themselves.
F
Very
very
good
point,
so
in
my
documentation,
I
actually
said
I
think
core
Dev
here
should
align
no
matter
what
we
should
commit
to
perform
like
ship,
one
upgrade
for
the
community
in
q1.
If
fbm
further
slip
to
your
timeline,
that
is
going
to
be
post,
you
know,
after
like
March,
we
should
still
should
perform
an
upgrade,
but
including
other
protocol
changes
that
will
benefit
the
network.
What
that
means
is
like
even
an
fsdm
is
not
gonna.
F
For
now
it's
not
gonna
be
included
in
in
the
80
implementation
team
should
start
implementing,
SDM
and
and
the
other
47
to
have
the
code
ready
and
to
ship
in
March.
If
necessary.
A
Also
a
quick
side.
Note
I
can't
see
the
chat,
although
I
can
see.
There's
a
lot
of
comments
coming
in.
A
So
if
you
do
have
a
question
either
Jennifer,
if
you
could
call
on
people
or
folks,
if
you
could
raise
your
hand,
my
question
is:
if
we
push
for
a
really
quick
upgrade
in
nb19,
specifically
focus
on
SDM
I
assume,
that's
not
going
to
give
us
enough
time
to
do
impact
modeling
on
gas
changes,
for
example,
for
fevm
and
nv18,
and
it's
not
going
to
necessarily
change
the
parameters
as
far
as
I
understand
it.
A
Around
migration
complexity,
so
is
actually
pushing
off
SDM
into
nv19,
going
to
substantively
change
the
risk
calculation
here
in
a
way
that
is
worth
doing,
a
very
quick
follow-on
upgrade.
A
I'm
sorry
does
that
question
make
sense:
okay,
yeah!
So
if
I
understand
correctly,
there's
like
two
major
issues
with
including
SDM
in
nv18
correct.
It
is
the
complexity
of
migration
for
sectors
regardless
of
whether
it's
all
sectors
or
new
sectors,
and
then
there's
also
you
just
risk
management
right,
we're
introducing
fpvm
we
introduce
sdm2.
It
may
be
very
difficult
to
accurately
predict
what
impact
it's
going
to
have
on
the
network.
A
What
I'm
asking
is
you
know
if
we're
saying?
Well,
maybe
we
should
consider
delaying
SDM
to
an
nv19
upgrade
very
quickly
after
nv18
and
we're
looking
at
potentially
a
timeline
of
only
six
weeks.
My
question
is
it's
almost
a
hypothetical,
but
as
it
is
six
weeks
really
enough
for
us
to
say
that
the
risk
or
our
ability
to
manage
or
measure
it
is
it
significantly
lower
to
Warrant
waiting
instead
of
just
including
it
in
NV
18.
F
F
The
potential
role
of
risk
is
like
acceptable
for
the
network
and
we
have
been
proven
so
like
just
by
the
shock
yourself.
The
the
only
thing
that
changes
like
again
Fe
VM
is
bigger
than
like
ever
so
like
that's.
Why?
We
don't
want
to
add
that
complexity
to
this
particular
upgrade.
F
So
if
you
it's
the
me19
again
at
first,
like
I,
don't
expect
anything
to
have
to
go
back
with,
like
migration
will
do
a
lot
of
testing,
but
if
it's
in
a
separate,
upgrade
I
think
it's
more
like
manageable
on
this,
like
roll
out
shot
but
like
I'm,
the
CE
impact
I'm,
not
the
best
person
to
answer
this
question
so
I'm
going
to
leave
it
to
others,
but
my
gut
feeling
is
like
if
evm
potentially
will
bring
crypto
like
you
know,
not
crypto
like
economy
changes
to
the
network,
and
it's
definitely
like
a
worse
mandatory
I
think
it's
up
to
the
courthouse
to
design
later
on,
how
long,
how
long
we
should
be
monitoring
the
network
and
and
then
further
consider
if
SDM,
yes,
still
the
resolution
for
the
problem,
we
are
trying
to
Target
to
solve
after
the
lunch.
G
Thanks
sorry,
I
have
to
switch
between
seven
screens
in
order
to
find
chat
on
mobile
yeah.
I
was
just
gonna.
Second
Jennifer's
point
that,
like
there's
gonna,
be
enough
complexity
with
analyzing
the
network
after
fcm
launches
and
and
monitoring
to
respond
to
challenges.
G
What
happened
last
time
is
our
monitoring
went
down
over
the
network
because
of
the
large
Network
upgrade,
so
we
actually
were
Flying
Blind
for
a
couple
of
hours,
which
is
always
a
very
concerning
place
to
be
in,
and
if
you
have
a
migration,
that's
happening
at
the
same
time,
you
increase
the
risk
of
that
sort
of
thing,
and
so
that's
why
decoupling
it
and
just
two
I,
don't
think
we're
scared
about
this
upgrade
in
particular,
we
just
don't
want
to
add
any
additional
moving
pieces
when
it
comes
to
fvm.
G
I.
Do
think
if
there's
a
way
that
you
can,
we
can
do
the
upgrade
or
you
can.
You
can
include
this
Improvement
that
doesn't
sacrifice
fdm,
then
that's
good,
but
we
don't
necessarily
want
to
take
a
yeah.
Do
an
improvement
that
we
think
is
subpar
or
like
not
effective,
not
good
for
the
network.
G
You
know
I
think
it
is
more
worthwhile
to
aim
for
doing
two
and
getting
on
a
Cadence
of
faster
Network
upgrades
I.
Think
that
is
a
good
healthy
place
for
the
Falcon
Network
to
be.
We've
talked
about
it
before
and
that
you
know,
but
that
I
think
that
goes
to
like
all
core
devs
like
can.
Can
we
aim
for
something
like
a
six-week,
Network
upgrade
after
fvm?
Is
that
feasible
Jennifer
to
your
point
on
like
trying
to
do
one
if
fem
slips
to
then
suddenly
switch
Pace
to
do
another?
G
One
before
like
I,
hear
I,
hear
you
and
I
I
like
yeah
like
that
sounds
great,
but
I
don't
think
in
practice
we
would
be.
We
would
make
that
choice
right
like
we'll
get
to
what
end
of
February
and
suddenly
to
switch
pace
and
try
and
do
a
different
network
upgrade
like
I.
Don't
think
we'll
end
up
in
that
situation
you
know
most
likely
and
so
I
think
it.
G
B
I
guess
one
more
question:
I
have
from
that.
That
makes
sense
just
really
quickly
from
like
a
being
expedient
perspective
when
something
is
implemented
and
also
when
it
goes
through,
the
governance
process
are
completely
decoupled.
Right,
like
it
doesn't
affect,
can
be
accepted,
and
then
it
can
be
implemented
whenever,
like
the
fact
that
maybe
it
might
not
be
implemented
in
the
protocol
on
NVA
team
is
not
a
reason
why
I
can't
enter
last
call
sooner.
A
That's
correct
and
also,
ideally
in
the
future,
we
shouldn't,
be.
You
know,
scheduling
things
for
last
call
for
an
upgrade.
We
just
have
to
do
that
for
expedient's
sake,
but
you're
right.
We
could
start
last
call
tomorrow
if
you
decided
that
was
prudent
for
what
your
team
is
proposed
and
still
say
it
will
go
in
an
Envy
19.
B
I
B
I
say
this
is
also
from
like
a
signaling
perspective.
It
may
even
it
may
be
good
for
people
to
know
that
something
like
an
STM
is
available,
especially
if
it
applies
for
all
sectors
and
that
that
will
happen
at
some
point
within.
Let's
say
the
next
three
or
four
months.
I
think
that's
a
good,
that's
good
for
people
to
have
that
that
knowledge
when
it
comes
to
their
business
planning,
especially
for
SPS.
A
For
what
it's
worth,
I
think
you're
right
and
my
preference
here
is
actually
for
that
very
reason
whether
we
I
don't
think
we
should
jump
into
last
call
immediately,
but
I
think
we
should
have
it
completed
before
we
publicize
or
become
very
vocal
about
nv19
I.
Think
it'll
give
us
some
good
distance,
while
still
allowing
us
to
be
quick,
I
think
that's
totally
correct.
F
And
if
you
follow
up
on
what
Molly
suggested
and
definitely
like
the
she
pointed
out
like
last
time,
like
our
monitoring
system
had
a
Fallout
on
the
note-
and
we
did,
we
didn't
have
a
monitoring
system
of
to
monitor
the
network
house
for
like
a
half
a
day
for
the
shark
upgrade
that,
like
we
did,
did
a
retro
with
the
team
and
I
identified
a
couple
Improvement.
F
We
can
make
in
Lotus
to
support
like
more
like
note
operations,
so
we
do
have
a
couple
solutions
that
we
we
have
in
in
the
backlog.
F
It's
just
like
implementing
those
like
taking
like
engineering
resources
and
I
had
80
percent
of
that
a
Lotus
engineering,
Lotus
Engineers,
are
fully
supported,
fev
and
development
right
now
so
like.
If
we
put
any
other
people
working
on,
you
know
improving
migration.
At
the
moment
a
year
may
slow
down.
Feb
and
development
like
like
also
like
Molly,
said
also
I.
Believe
Alex
mentioned
the
same
thing.
F
We
should
invest
more
time
to
identify
why,
right
now,
we
can
only
why
the
Falcon
Network
can
only
perform
an
upgrade
every
three
months
at
the
moment,
and
what's
the
Gap
like?
How
can
we
improve
that,
and
hopefully
we
can
ship
another
upgrade
like
sooner
and
included
like
SDM
changes
like
I
mentioned
earlier,
even
if
SDM
is
not
included
in
nv18,
we
tend
to
start
like
implementing
that,
just
so
that
you
know
the
solution
is
ready
whatever
and
like
whatever
we
are
ready
to
include
in
upgrade.
F
We
can
we
can
we
can.
We
can
like
act
on
it
and
last
but
not
least,
I
do
want
to
mention
in
the
past,
like
three
weeks,
there
are
other
Solutions
being
proposed,
including
this
one
like
fifth
discussion.
Eight
five,
eight
three
sauce
for
SPS
and
potential
solution
is
a
lot
of
those
Solutions
propose.
Our
mission
can
be
implemented
on
Smart
contract
on
top
of
fevm,
so
that
opens
up
more
opportunity
for
us
on,
like
you
know,
on
us
like
for
us
back
in
the
future.
I
Yeah
thanks
I
just
want
to
summarize
what
we're
chatting
about
in
the
in
the
chat
as
well.
I
think
we
we
fully
are
on
the
same
page
regarding
like
we
should
ship
fevm
sooner
and
then,
if
we
can
commit
to
like
six
weeks
right
after
that
sounds
good,
but
I
mean
that's
something
that
we
can
still
discuss.
I
But
then
the
other
thing
is
I.
Think
from
our
side,
I
think
the
conclusion
from
the
analysis
was
having
SDM
any
form
sooner
is
like
always
better
and
I.
Think
the
hold
up
from
our
read
is
the
state
migration
right
and
that's
why
I
was
pushing
back
and
challenging
online
I
was
one
I
want
to
dig
deeper
into
what
exactly
that
result
in
the
state
migration?
I
If
so,
in
our
in
our
mind,
when
we
say
all
sector
I
think
like
what
we
just
mean
that
we
enable
SDM
for
extension,
but
when
we
say
new
sector
you
just
be
like:
oh
you
get.
Oh
you
only
get
it
when
you
add
like
a
new
sector,
so
there
could
be
a
role
where
we,
let's
say,
there's
like
no
State
migration
needed
for
new
sectors.
We
we
only
do
that
for
new
sectors,
for
let's
say
Network
18
right,
so
that
shouldn't
add
any
state
migration
cost.
I
And
then
we,
if
we
were
to
follow
up
to
enable
any
of
to
enable
any
of
the
extension,
then
we
could
do
that
in
a
separate
upgrade.
J
Yeah
so
I
don't
know
if
we'll
be
able
to
Hash
it
out
right
now,
but
so
we
were
talking
a
bit
in
the
chat
myself
in
the
CX
So.
After
talking
with
Tom
today
and
just
looking
over
the
FIP
and
trying
to
understand
some
of
the
implicit
assumptions,
it
really
looks
like
we
do
need
another
field
in
the
sector
info
if
we
want
to
get
the
power
based
off
of
sector
info.
So
a
requirement
of
the
system
is
that
we
can
compute
QA
power
just
from
a
raw
sector
info.
J
In
order
to
do
that
with
the
new
SCM,
we
need
to
compute
svm
from
sector
info
and
the
thing
the
thing
that
I
learned
today
is
that
svm
moved
upon
an
extension
should
not
reflect
the
total
lifetime
of
the
sector
from
activation
to
like
latest
expiration,
but
should
rather
reflect
the
time
period
from
latest
extension
points
or
base
power,
Epic
from
related
concept
of
Alex
to
the
to
the
upcoming
expiration.
And
this
means
we
don't
have
enough
information
inside
of
the
sector
info
to
get
this
STM.
J
One
thing
that
kind
of
came
up
in
the
chat
was
that
if
we
wanted
to
create
a
requirement
that
no
sectors
that
no
new
sectors
made
after
mb18
can
be
extended,
then
we
could
probably
get
SDM
without
a
migration.
But
that
seems
like
probably
unworkable.
I
think
that
that
is
like
the
the
place.
We'd
have
to
go
to
to
get
SCM
working
without
a
migration.
F
Thank
you,
Sam.
There's,
a
suggestion
in
the
chat
is
like
to
take
further
design
discussion
to
another
venue
just
to
over,
communicate
like
say
x,
when
we
say
the
migration
is
needed
for
sector
extension,
it's
not
for
a
sector,
it's
not
for
like
SDM
applied
to
existing
sectors
and
for
existing
sectors
to
enjoy
SDM.
Upon
extension,
it
applies
to
any
sectors
ordered
after
SDM
USSA
and
to
further
extend
it
like
in
the
future.
It
requires
a
migration.
Maybe
that's
a
that's
a
gap
here.
I.
I
F
Good
Alex
has
a
hand.
D
Yeah
thanks
I'm,
somewhat
more
I
I'm
a
bit
more
enthusiasm
than
Molly
for
exploring
how
we
can
be
prepared
to
if.
D
Up
slipping
the
timeline,
which
you
know
three
months
out
or
two
months
out,
still
reasonably
possible
being
prepared
to
ship
an
SDM
related
set
like
basically
everything
else
except
the
VM.
That's
in
this
trade-off
I
think
it's
worth
exploring
how
to
make
that
possible.
D
There
will
be
some
like
cut
off
date
where,
like,
if
we
don't
launch
the
test
net
with
this
new
thing
by
you
know
this
state,
then
you
know
can't
hit
some
date,
but
I
do
think
it's
worth
us
trying
to
understand
what
would
need
to
be
true
for
us
to
do
that
and
doing
the
implementation
work
for
STM
914
fit
47
like
you
know,
getting
that
all
up
into
our
into
a
integrated
branch
that
we
can,
that
we
could
turn
into
a
network.
D
I
I
would
hate
to
be
in
a
situation
where,
where
it
is,
you
know,
February
and
fbm
is
not
gonna.
You
know
is
not
going
to
make
that
much
that
you
know
they're
behind
by
by
two
weeks
or
whatever
I
don't
want
them
to
be
in
a
place
where
this
intense
time
pressure
from
continually
setting
targets
and
missing.
You
know
causes
them
to
make
bad
engineering
decisions,
we're
in
a
way
worse
state
if
they
make
a
poor
engineering
decision
because
of
time
pressure,
and
you.
D
Back
in
hindsight
and
say
man
I
wish
we
just
done
the
SDM
in
January
and
then
FM
was
going
to
be
in
April
anyway,
yeah
I'm
not
saying
we're
going
to
be
April,
but
we
have
an
opportunity
here
for
a
much
generally.
You
know
tightly
scoped
upgrade
that
can
step
in
and
provide
great
benefit
to
the
network
if
the
fvm
is
still
underestimating
the
complexity.
D
F
Can
this
is
something
maybe
I
can
take
out
like,
maybe
where
I
can
work
on
like
maybe
next
starting
like
next
Monday
is
to
say,
if
we
only
do
SDM
and
like
say
47
and
the
activation
bug
fix,
what's
the
engineering
timeline
looks
like
and
the
what's
you
know
the
the
deployment
timeline
looks
like
and
gave
whatever
update
and
some
kind
of
timeline
and
for
this
decision
making.
D
Yeah
and
I
expect
there's
not
a
whole
lot
of
code
involved
there.
You
know
the
biggest
one
is
already
written
47.,
it's
it's
integration,
work
and
so
on
and
I
saw
already.
You
filed
an
issue
for
prototyping
the
SDM,
which
will
flush
out
any
remaining
dependencies.
C
H
C
I
want
to
see
if
we
were
all
on
the
same
page
about
the
work
needed
from
my
perspective,
it's
obviously
prototyping
and
actually
prototyping
implementing
and
integrating
the
sdn
slip
itself
Landings
at
47,
which
is
in
a
reasonable
state
that
to
be
done,
make
of
getting
the
designs
themselves
and
implementing
the
migrations
for
them,
and
this
is
honestly,
where
we've
often
wound
up
running
into
issues
bugs
and
so
on.
C
So
one
suggestion
I
would
make
is
to
be
very
clear
about
what
migration
stuff
is
needed
from
the
get-go
and
then
kind
of
you
can
you
can
treat
it
as
optional,
improving
client-side
migration
performance
impact?
This
is
a
bit
of
a
learning
that
we
got
from
the
shark
upgrade
where
one
of
the
migration
was
successful
and
the
network
was
obviously
fine.
C
Our
users,
at
least
Lotus
users,
were
a
little
unhappy
and
we
were,
as
hardly
said,
we
were
in
a
bad
place
for
somewhere
between
2
and
12
hours
and
I
know
this
kind
of
panic.
We
were
success
before
we
had
a
lot
of
migration,
so
ideally
we'd
get
to
that
as
well.
That
is
not
the
most
amount
of
work.
That's
not
the
largest
volume
of
work,
especially
as
you
know,
the
FM
continues
to
develop
it's
a
core
part
and
deals
with
Audits
and
so
on.
C
So
from
that
perspective,
I
think
if
we
can
find
owners
for
these
issues
and
if
you
can
number
one
come
to
a
decision
tonight
and
find
owners
for
these
issues
for
the
various
work
streams,
I
think
there's
an
argument
that
it
is
doable
that
I'll
March
1st
to
March
15th
timeline.
Obviously
we're
talking
about
a
fifth
that
hasn't
been
written,
let
alone
accepted
yet
I
think.
C
But
if
there's,
if
there's
anything,
I'm
missing
or
if
they're
trying
to
surprises
people
I'd
like
to
quickly
just
like
raise
those
slides
now
because
I
think
that's
very
German
into
this
position.
F
L
K
Yes,
I
understand
you
that
we
have
a
the
your
childhood
here
so
yeah.
Fortunately,
we
have
yeah
if
we
support,
if
UVM
I
think
that's
usually
okay,
it's
because,
if
you
remember,
is
actually
about
the
yeah
building
actors
right
so
yeah
well,
do
the
integration
and
also
some
other
updates
that
will
be
fine
yeah
for
the
back
region.
K
If
we
support
SDM,
we
may
need
a
little
bit
longer
time,
but
I
was
like
that.
If
we
only
support
the
new
sectors
yeah,
we
need
to
yeah,
it
might
be
okay,
but
it
yeah.
It
will
also
depends
yeah,
depending
on
how
many
times
how
many
days
the
team
will
take
for
the
vacation.
L
F
There
we
also
need
to
take
into
consideration
that,
like
a
Venus
team
also
have
to
be
implementing
febm
into
into
their
implementation
as
well
on
related
features,
so
you
might
take
some
resources
already
okay,
so
we
are
almost
time
again,
like
I
mentioned
earlier,
that
I
do
believe
it's
it
Network's
best
interest.
We
have
been
having
this
conversation
for
the
past
two
months.
Now,
it's
whatever
on
the
scope
of
evina
18
Again,
a
lot
of
people
are
waiting
for
an
update,
I
and
I.
F
Think
we
do
have
enough
information
data
points
that
we
have
been
considering
over
the
past
like
months.
I
still
think.
The
goal
for
today
is
like
for
us
to
have
the
consensus
on
what
we
should
do
on
MBA
team,
but
like
with
very
precise
next
steps.
Giving
everything
that's
being
mentioned
here
is
my
summary.
F
We
are
gonna
stay
this
we're
gonna
like
are
you
sure,
I
heard
you
it's
like
if
we
have
like
additional
resources,
maybe
help
us
implementing
migration
like
maybe
we
can
make
everything
for
the
March
first
but
like
to
me.
It's
like
again
a
very
optimistic
like
saying:
we
should
not
plan
our
imaginary
resources
that
just
coming
up,
we
don't
want
to
stop.
You
know,
sub
touch
the
febm
timeline,
so
I
do
have
my
reservation
on
that,
so
I'm,
gonna
I,
hope.
You
understand.
F
I
think
you
understand
because
I
see
you
are
like
not
in
the
head
a
little
slightly,
but
so,
with
everything
being
said,
what
I'm
gonna
say
here
is:
keep
the
scope
as
it
is
to
ship
fevm
commit
to
the
March
first
like
timeline
as
it
is
today,
with
the
precise
action
item
being
one
team,
should
a
dri
should
be
appointed
to
start
implementing
SDM
a
dri
should
be
appointed
to
implement
the
two
to
drive
like
lending
fit
47
a
dri
should
be
appointed
to
fix
the
activation
bug,
which
is
beauty
actor
issue.
F
914
ndri
should
be
appointed
to
analysis,
the
the
timeline
and
the
cut
time.
The
cut
off
timeline
of
fbv,
if,
like
FB
ffebn
code
freeze,
doesn't
happen
by
this
date.
That
means
we
will
switch
the
context
of
mb18
to
SDM
and
then
then
the
dri
should
be
appointed
to
analysis.
How
can
we
perform
another
upgrade
sooner
after,
like
in
general
for
the
longer
term,
but
especially
after
febm,
to
include
STM?
So
after
we
should
commit
to
implement
I
guess
like
the
con,
the
consensus
is
like
we.
F
C
I
agree
with
almost
everything
you
said:
I
think
the
only
thing
I
would
suggest
to
change
too
is
in
terms
of
that
cutoff
date
where,
if
we
see
the
fpvm
move
this
code
3
flipping
instead
of
saying
that
SDM
will
jump
the
queue
along
with
any
other
changes.
We
want
to
make
I
think
the
right
thing
to
do
at
that
point
is
to
say
we
will
incorporate
it
into
Network
version.
18.
C
I
think
that's
the
I
think
that's
a
better
way
to
achieve
to
protect
our
interests
so
to
be
happy
on
this
timeline.
Well,
also
accommodating,
but
also
not
allowing
this
to
sit
unchanged
for
longer
than
it
takes
you
extremely
wrong
with
them.
D
Maybe
that
discussion
can
go
and
be
on
this
meeting.
But
my
first
position
is
that
our
like
commitment
to
not
breaking
the
network
that
we
that
we're
holding
by
taking
the
fbm
on
its
own
first
I
think
it's
a
reasonably
strong
thing
to
take
as
our
first
priority
and
so
I'd,
rather
not
do
them
both
at
once.
F
Also,
to
reiterate
CL
that
suggests
stdm
should
land
a
song,
I
writers
and
later
for
the
Network's
lesson
interest
Okay.
So,
with
everything
being
said,
official
Vault
pulling
sentiment
polling
is
that
the
work
that
we're
using
anyone
that
has
strong
objections
on
on
the
final
final
scope,
with
everything
consider.
C
Not
no,
which
is
why
I
want
someone
likes
to
go
for.
C
F
C
J
C
I
I,
don't
I,
don't
say
one
thing,
and
this
is
a
lot
of
strong
objection,
but
just
as
we
all
think
about
better,
we
wish
sometimes
but
I'm,
really
happy
here.
I
think
the
difficulty
that
I
personally
am
facing
when
I
asked
to
make
a
recommendation
here
is
I'm
not
sure
what
to
optimize
for,
because
we're
trying
to
protect
a
bunch
of
different
things
at
once,
we're
trying
to
protect
the
equilibrium's
timeline,
acknowledging
the
fpvm
as
the
important
or
an
important
Improvement
that
will
be
landing
in
style
coin
in
this
quarter.
C
We're
trying
to
protect
the
poor,
rep
security
of
the
network
and
that's
actually
47,
and
so
on,
gets
factored
and
we're
trying
to
protect
the
crypto
Economic
Security
of
the
network,
which
I
will
admit,
is
something
that
I
don't
personally
understand
as
well
and
therefore
have
a
harder
time
engaging.
You
know,
timelines
and
impacts
and
then
we're
trying
to
protect
things
like
user
impact
of
a
complicated
migration
and
like
the
reputation
damage
to
the
fpvm.
C
If
the
network
upgrade
lines
are
being
problematic
because
of
the
migration
and
so
on,
which
is
a
less
important
than
somewhat
Messier
domain.
I,
don't
know
which
one
to
prioritize
it
I
feel
like,
depending
on
what
we
treat
is
the
most
important
I
come
up
with
different
answers
in
terms
what
I
would
personally
recommend
I,
don't
know
so
I
think
for
me.
When
we
talk
about
like
whether
we
have
objections
or
whether
we
will
treat
consensus,
it's
slightly
concerned
to
which
of
those
very
orthogonal
domains
to
to
prioritize.
B
I
guess
I
have
one
more
point
from
maybe
like
a
more
practical
perspective
regarding
what
moving
forward,
we
did
say
that
governance
and
implementation
are
decoupled.
So
do
people
here
think
that
it's
best
for
CEO
to
just
move
forward
with
last
call,
regardless
of
what
is
decided
to
hear
in
terms
of
implementation,
just
so
that
we
know
that
this
FIB
will
be
a
part
of
the
network
and
then-
and
then
that
is
decided.
You
know,
the
implementation
part
can
follow
from
this
discussion.
D
It
depends
a
little
bit
what
you
mean
by
implementation
pot
like
the
fit
pass
to
fully
specify.
What's
going
to
happen,
including
all
these
decisions
about
whether
we
need
a
migration
and
what
state
we
need
to
store
and
those
things,
but
given
a
fully
specified,
fit
I.
Yes,
100,
you
know,
let's,
let's,
let's
get
it
into
law
school.
B
So
if
people,
if
implementers
here,
don't
think,
there's
anything
glaring
missing
from
the
spec
of
the
FIB
itself,
it
seems
to
me
that
you
know
CEO
will
propose
the
version
of
the
fit
that
is
best
for
the
network
that
can
be
accepted
or
not
depending
on
what
happens
in
the
last
call
period
and
then
implementers
will
you
know
whether
or
not
it's
an
NBA
team,
nv19
or,
however,
however,
that
that
shakes
out
is
completely
separate
from
the
FIP
being
accepted
when
it
comes
to
governance,.
F
I
I
feel
like
we
are
not
we,
we
kind
of
didn't
have
the
best
like
habit
here,
but
like
I
always
feel
like
the
writing
and
governance
process
should
like
happens
way
before
we
have
to.
You,
know,
cut
the
holes
to
Network
upgrades
so
like
once,
you
have
the
fit
ready.
I
think
it
also
should
propose
the
best
advice
changes
for
the
network
like
it
goes
through
the
governance
process,
and
then
we
can.
B
A
Yeah
final
Point,
too,
we
have
a
lot
of
fips
that
are
on
the
verge
of
being
ready
for
last
call
and
knowing
that
we're
not
going
to
include
for
right
now,
SDM
and
the
in
nv18,
we
can
sort
of
like
promote
its
last
call
separately
so
organizationally.
It
might
help
with
some
of
the
Community
Management
too
so
yeah
to
reiterate,
generate
Jennifer's
point
that
we
should
leave
with
firm
consensus
and
not
waver
from
it.
F
Cool
yeah.
This
is
definitely
like
one
of
the
tough
ones
and
I'm
also
like
again
like
looking
for
like
feedbacks
on
like
how
this
process
like
we
never
had
such
like.
You
know,
seated
or,
like
you
know,
discussion
we
had
but
like
this
is
one
of
this
one
so
like.
If
you
have
any
feedbacks
on
how
we
should
proceed
and,
like
you
know,
make
the
best
decision
for
the
network,
please
steal
that
case
clean
know.
F
We
are
trying
to
Improvement
improve
like
how
core
Dives
should,
like
you
know,
support
a
network
so
but
yeah.
If
you
have
any
feedbacks,
let
us
know
awesome
cool.
A
Sure
yeah,
so
Steph's
still
out
of
office,
we'll
try
and
get
meeting
notes
up
ASAP,
since
there
was
a
lot
of
important
information
today.
I
also
want
to
say
thanks
so
much.
Everyone
worked
really
hard
over
the
last
couple
of
weeks,
which
is
incredible.
Considering
all
the
holidays
and
I
think
it's
really
important.
That
folks
did
that
and
really
appreciated.
A
Also
I
know
it's
always
really
hard
and
every
upgrade
is
pretty
unique,
but
I'm
actually
really
impressed
by
how
we
have
been
able
to
make
decisions.
I
know
it
doesn't
always
feel
that
way,
but
this
is
a
really
orderly,
concise
and
clear
call,
and
so
thanks,
everyone
for
bringing
your
opinions
I
think
we're
actually
getting
a
lot
better
at
this,
and
that's
a
really
really
good
thing.
So
thanks,
Vic
and
Jennifer
also
for
leading
your
conversations-
and
we
will
see
everyone
next
month,
foreign.