►
From YouTube: Filecoin Core Devs #38 (Meeting 1)
Description
Recording for: https://github.com/filecoin-project/tpm/issues/93
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,
hello,
everyone
and
welcome
to
meeting
number
one
today,
core
devs
meeting
number
38.
today
is
march
10th
and,
as
always,
we're
excited
to
get
started.
I
just
realized
the
date
is
wrong
on
our
presentation
slides.
So
let
me
make
a
change
real,
quick.
A
A
All
right,
can
everyone
see
my
screen
all
right?
Okay,
so
thank
you
to
everyone
who
sent
in
their
updates
for
the
week.
The
schedule
for
today
we're
gonna
go
through
key
items
from
all
of
the
implementation
teams
updates
from
file
queen
foundation,
both
network
governance
and
security
very
quickly
and
today,
as
previously
we're
going
to
focus
on
talking
about
the
three
network
upgrades
that
others
have
been
having
conversations
around
over
the
last
couple
of
weeks.
A
First,
this
is
our
first
meeting
since
the
v15
network
upgrade
so
congratulations
to
everyone
who
worked
so
diligently
on
it,
and,
although
I
don't
know,
if
we're
going
to
have
a
ton
of
time,
I
did
want
to
take
a
few
minutes
and
really
just
have
sort
of
a
quick
session
where
anyone
can
provide
any
additional
feedback
summaries.
Any
things
they
think
would
be
helpful
as
we
continue
to
plan
for
more
upgrades.
A
We
want
to
make
sure
that
we
hear
your
thoughts
and
feedback
about
this
one
first
and
then
we'll
go
into
a
presentation
about
our
current
thinking
for
both
v16
and
v17,
including
preliminary
timelines
and
fits
and
we're
excited
that
raul
has
joined
us
once
again.
To
give
a
presentation
about
the
newest-
and
I
think
last
for
now,
fdm
fips
that
were
just
pushed
into
the
fips
repo.
A
All
right,
so
with
that
forest
team,
do
you
want
to
kick
us
off
and
provide
your
updates
for
the
week.
C
Sure,
thank
you,
caitlyn
for
the
cordeco
yeah
on
our
side.
We
are
mostly
preparing
for
the
v16
network
upgrade
and
the
forest
repository
is
going
through
some
of
the
refactoring
to
just
improve
performance
changes,
enable
faster
things
and
include
more
test
coverage
and
that's
kind
of
what
we
are
focusing
on
at
the
moment
and
that
will
be
all
on
our
site.
A
Great,
I
know
you're
working
very
closely
with
lotus
team
with
the
fbm
team.
Any
open
questions
asks
from
or
for
the
forest
team
this
morning.
A
All
right
short
and
sweet.
Thank
you.
Lee
maxim
who
usually
joins
us
from
the
fujon
team
was
unable
to
today,
but
I
do
think
there
may
be
some
other
folks
joining
us
from
fujon.
Do
you
want
to
quickly
introduce
yourselves
and
do
any
or
either
of
you
want
to
provide
this
week's
team
updates.
D
Yeah,
thank
you.
I'm
alexey,
I'm
from
team.
My
famous
person
today
he'll
be
on
the
next
meeting
meeting
and
what
we
have
now
is
that
we
established
we
have
established
a
node
and
miner
on
mainnet
and
we
want
to
work
it
for
a
while
and
to
see
how
it
works.
We
are
developing
our
cli
and
we
have
implemented
such
a
lot
of
70
calls,
and
now
we
are
working
on
snap
deals
upgrade
we
are
testing
it
and
resolve
some
issues.
A
Great,
thank
you,
and
I
did
want
to
quickly
ask
snapdeal's
upgrade
is
being
reviewed,
is
one
of
the
updates
that
I
received
from
maxim.
I
was
wondering
if
you
could
briefly
sort
of
explain
what
that
process
means
a
little
bit
more.
D
We
need
to
completely
test
it
and
to
resolve
the
issues
that
we
will
find
during
this
test.
I.
A
A
D
It's
fsm,
which
is
based
on
lotus.
We
have
almost
the
same
states.
Maybe
we
just
keep
several
states
for
simplicity,
so
it's
very
close
towards
one.
A
All
right,
then,
we
will
jump
over
to
the
lotus
team
alexi.
Thanks
again,
I
think
jennifer.
You
probably
have
some
updates
for
the
team.
E
Yeah,
as
always,
we're
having
busy
weeks
at
loneliness
team.
First
of
all,
we
shipped
our
snap
upgrade,
which
was
great.
We
follow
up
with
a
couple
like
bug,
fixes
to
improve
storage
providers,
user
experience.
E
And
then
we
are
shipping
115-0
today,
with
a
lot
of
like
retrieval
improvement,
especially
from
the
client
side,
to
speed
up
paid
retrieval,
and
then
you
know
a
more
storage
provider,
user
experience
like
improvements,
bug
fixes
and
like
new
features.
As
seen
like
normal
scenes
ongoing,
we
are
working
very
closely
with
routes
like
fvm
team
hacking,
the
fvm
reference
implementation
itself,
bringing
like
v7
built-in
actor,
ready
and
working
towards
v8
actor
for
network
version
v16
and
we're
focused
on
boosting
actor
test
coverage.
E
E
If
you
can
help
feel
free
to
assign
yourself
a
ticket
and
like
contributing
and
the
prs
and
then
we
are
ready
to
work
on
fibs
31
in
the
lotus
land,
and
then
we
will
be
like
launching
a
canary
fvn
v0
tag
that
will
use
fvm
and
v7
built-in
actors,
thinking
network
b15
next
week
and
testing
with
our
spx
finals,
and
then
we
are
going
to
work
towards
fifth
31
and
hopefully
launching
in
butterfly
soon
and
also
for
our
regular
march
rubies.
15
one
is
going
to
be
tagged
next
tuesday.
E
This
include
like
indexer
providers,
which
is
like
you
can
announce
your
deal
indexings
to
the
indexer
node,
which
will
be
the
foundation
of
the
retrieval
market
in
the
future.
So
it's
basically
content
address
content
addressing
so
that's
super
cool.
We're
also
going
to
have
a
lot
of
like
the
p2p
resource
manager,
improvement
and
graph
sync
improvement,
so
yeah,
exciting
stuff.
A
All
right
so,
as
mentioned
before,
we
do
not
have
a
representative
from
the
venus
team
this
morning.
Many
of
them
are
in
eastern
asia,
so
I
expect
they'll
be
on
this
afternoon's
call
instead,
but
they
have
mostly
been
focusing
on
venus
cluster
upgrades
this
week,
which
is
a
provision
for
helping
with
sector
stealing
times
a
couple
of
things
that
they've
been
able
to
ship
and
they're
focused
on
implementing
snap
deals
next
week.
A
All
right
sounds
great,
then,
updates,
as
always
from
the
file
queen
foundation
from
the
governance
side.
We
have
a
lot
of
open
fips
that
we're
currently
tracking.
We
obviously
have
the
four
current
fbm
fips
that
are
open,
which
again
raul
will
talk
us
through
the
latest
iteration
of
those.
We
also
have
a
couple
of
fips
that
have
been
merged
into
the
repo
and
we're
waiting
on
last
call
to
understand
a
little
bit
more
about
what
we'd
like
to
implement.
A
If
you
have
not
looked
at
any
of
these
previously
or
if
there's
a
new
one
that
maybe
didn't
catch
your
eye
previously,
just
a
reminder
that
we
do
ask
that
everyone
does
review.
At
least
cursory,
take
a
look
at
what's
being
proposed,
etc,
and
if
you
need
links
to
any
of
these
or
would
like
me
to
walk
you
through,
what's
currently
there
and
open
and
gathering
feedback,
I'd
be
happy
to
do
so
and
as
an
update,
also
we're
looking
to
consistently
improve
communication
around
fips.
A
There
are
so
many
that
are
coming
in
as
well
as
new
discussion
post
topics
so
starting
this
week.
Officially,
we
will
have
a
long
form
governance
update
published
in
github,
and
we
also
now
have
a
long-form
deep
dive
into
the
fips
process
that
was
pushed
to
github
this
week
or
added
as
a
discussion
forum
topic.
A
If
you
want
to
review
that,
I
highly
recommend
it
to
understand
how
we're
thinking
about
each
step
in
the
fits
process,
not
just
for
implementers
or
core
devs,
but
also
for
community
members,
and
as
always,
this
is
sort
of
an
iterative
process.
So
if
you
have
open
questions
that
you
think
are
unaddressed
currently
feedback
or
asks
for
additional
documentation,
now
is
definitely
the
time
to.
Let
me
know
so,
of
course,
links
to
that
post
in
particular
will
be
added
to
notes
and
I'd
be
happy
to
send
it
to
you.
A
All
right
and
I
think
dudley
just
joined
us
dudley.
Do
you
have
any
updates
from
filecoin
security.
A
Great
all
right,
so
it
looks
like
jennifer
may
have
just
added
this
slide,
because
I
have
not
previously
seen
this
graph,
but
again,
as
mentioned,
we
wanted
to
take
a
moment
to
provide
everyone's
space,
to
provide
feedback
and
insight
into
how
your
team
managed
the
most
recent
network
upgrade.
Perhaps
jennifer.
Do
you
want
to
kick
us
off
and
walk
us
through
what
you've
added.
E
E
A
Yeah,
that's
great
and
also
tangentially.
The
file
green
plus
team
also
has
really
good
statistics
about
how
they're
onboarding
data
into
the
network.
Currently,
I
think
they
just
reached
the
50
threshold
where
now
more
than
half
of
all
deals
on
the
filecoin
network
are
verified
and
actual
rate
of
onboarding
has
increased
exponentially
in
recent
weeks.
A
A
But
that
being
said,
I
wanted
to
just
again
leave
this
as
an
open
space.
Does
anybody
have
any
feedback
or
any
thoughts
they'd
like
to
share
about
the
recent
network,
upgrade
specifically
related
to
sort
of
the
process?
That
was
that
we
went
through
how
clearly
communicated
were
expectations
and
timelines?
A
B
I
mean
I,
I
have
some
thoughts,
I'm
very
interested
in
hearing
from
the
other
teams,
but
I
I
think,
for
speaking
kind
of
on
behalf
of
lotus.
The
hardest
part
of
this
upgrade
felt
like
it
revolved
around
testing.
It
was
obviously
a
complicated
upgrade
with
various
moving
pieces.
Proofs
had
to
get
their
work
done,
trusted
setup
was
happening
and
and
then
as
clients
we're
mostly
consuming
the
outcome
of
those
of
those
efforts.
B
For
me,
I
felt
like
everything,
yeah
went
roughly
smoothly
until
we
essentially
got
to
our
almost
ready
phase,
and
then
it
was
the
getting
from
almost
ready
to
this
is
secured.
This
is
tested,
we're
all
on
the
same
timeline.
B
It
felt
like
the
messier
part,
so
potential
some
things,
some
useful
learnings
that
I
think
that
for
me,
from
this
kind
of
as
a
retro
number,
one
us
having
a
dedicated
test
network
just
for
the
upgrade
worked
pretty
well,
and
it
was
thanks
to
the
infra
teams
that
we
were
able
to
make
that
happen
quickly.
B
Obviously
we
have
the
calibration
test
network
but
that
one's
important
that
one
we
can't
afford
to
take
risks
with,
because
you
know
there's
a
lot
of
external
stakeholders,
so
I
do,
I
think,
I'm
interested
in
the
idea
of
making
that,
like
a
mainstay
for
our
for
our
network,
upgrade
testing
number
two,
I
think,
having
other
implementers
join
testing
efforts
is
really
really
important.
We've
had
this
learning
a
few
times,
but
I
think
yeah.
B
I
I
like
the
direction
that
we
had
that
we
were
starting
to
headed
towards,
as
we
were
approaching,
the
upgrade
of
we're
all
on
calibration
net.
Let's
all
kind
of
do
some
of
these
sanity
checks
to
test
the
migration
test.
The
upgrade
are
we
all
on
the
same
page?
Are
we
getting
the
same
results
and
so
on
it'd
be
nice?
If
we
continue
definitely
continue
that
effort
and
give
it
momentum,
otherwise,
yeah.
The
only
other
piece,
I
think
is
I.
It
can
often
feel
difficult.
B
The
testing
stage
can
feel
difficult
for
the
lotus
team,
specifically
because
when
we
discover
issues
we
don't
know
whether
it's
some
an
issue
in
lotus
that
we
need
to
deep
dive
on
and
fix
and
so
on,
or
if
it's
an
issue
in
any
of
the
new
features
and
say
proofs
or
actors
or
any
of
the
other
dependencies.
Once
we
have
the
fvm,
we
won't
know
if
the
problem
is
in
lotus
or
in
the
fem,
and
that
can
lead
to
a
bit
of
a
complicated
position
of
how
much
time
do
we
spend
on
this.
B
Before
saying,
I
think
this
is
a
dependency
that
we're
consuming.
That
has
a
problem,
I'm
guessing
other
teams
are
in
a
similar
position.
I
don't
really
know
the
answer
to
that
question
is,
and
it
can
often
feel
frustrating
yeah
so
that
one
is
potentially
a
little
bit
of
an
unsolved
problem.
Yeah.
Those
are
my
thoughts.
A
Anyone
else
have
any
feedback
or
comments
or
agreement
with
what
I
just
said.
A
So
great,
thank
you
again
if
you
do
have
any
additional
feedback
that
anyone
would
like
to
add,
but
you
don't
want
to
share
in
the
meeting
again.
This
is
an
open
meeting,
so
we
do
encourage
you
to
be
open
with
the
other
implementers.
A
But
you
are
also
welcome
to
message
me
directly
and
we
can
take
that
feedback
into
consideration
when
trying
to
plan
and
make
organizational
decisions
again
around
future
upgrades,
but
thank
you
both
ayush
and
jennifer,
all
right
and
with
that
as
before
raw,
we'll
kick
it
over
to
you
to
help
us
talk
through
some
of
the
fips
that
you
recently
pushed
related
to
the
fvm
and
just
as
a
quick
flag
before
we
dive
into
those
we
had
previously
discussed
timeline
around
this
upgrade
we
had
agreed
to
it
and
we
eventually
decided
that
pushing
it
out
an
additional
week
is
going
to
be
necessary
to
provide
further
space
for
testing
for
all
teams.
A
So
this
is
the
current
network
timeline
that
is
being
considered.
I
think
we're
99
of
the
way
towards
confirming
that
this
is
what
we
use,
but
I
did
want
to
flag
this.
The
dates
are
just
slightly
different
from
what
was
discussed
previously,
so
please
flag.
If
this
is
a
concern
for
your
team,
but
I
think
far
and
away
most
people
like
having
a
few
extra
days
on
testnet,
just
in
case
great
thanks
and
raul
over
to
you.
F
All
right
cool
thanks
thanks
for
that
presentation.
Yesterday
day
before
yesterday,
in
the
last
few
days,
we
submitted
two
flips
that
had
that
were
the
remaining
fips
for
the
for
the
current
state
of
the
fpm.
F
We
had
initially
imagined
submitting
just
a
single
fit
for
all
gas
model
changes,
but
as
we
drafted
that
fit,
we
realized
that
there
were
really
two
categories
of
changes
that
we
needed
to
make,
and
these
would
be
activated
at
different
times
in
the
network,
so
therefore
kind
of
like
putting
them
together
and
bundling
them
into
a
single
fit.
F
Wasn't
the
best
way
to
create
and
foster
constructive
discussion,
because,
like
some
items
that
were
on
track
for
m2,
were
a
little
bit
premature
to
to
to
discuss
at
this
stage
and
to
and
would
hinder
getting
to
consensus
for
the
other
items
that
were
important
for
m1
and
concretely
for
for
nb16.
F
So
that's
why
we
decided
to
to
to
split
this.
This
fit
this
large
gas
model
flip
into
two
fips
fib:
zero,
zero!
Thirty
two!
This
is
what
we're
calling
the
gas
model
adjustment
for
the
non-programmable
fvm
and
then
a
fib
that
still
needs
to
be
numbered.
We're
calling
fib
and
and
n,
and
that
is
the
gas
model.
Adjustment
for
user
programmability,
so
basically
kind
of
like
the
heuristic
that
we
took
is
well
in
this
initial
febr032.
F
We
want
to
introduce
we're
proposing
to
introduce
what
we
call
an
execution
gas,
so
this
is
a
new
category
of
gas
that
is
going
to
be
charged
for
actual
logic
that
is
executed
in
the
actor.
Currently
it
is
that
goes
into
the
details
of
why
this
why
we
are
while
we're
introducing
this
this
execution
gas
and
why
it
hasn't
existed
in
the
past,
but
kind
of
like
the
lowdown
here
is
in
the
past.
We
didn't
have
with
native
actor
implementations.
F
We
didn't
have
a
portable
execution
byte
code
that
we
could
instrument
and
charge
for
the
logic
in
a
homogeneous
manner
across
all
implementations,
so
really
compute
on
the
actors
was
going
and
charged,
and
we
were
only
charging
for
cisco.
So
now
that
we're
opening
up
or
we're
paving
the
way
to
open
up
the
network
for
arbitrary
logic,
running
on
that
network
deployed
by
users,
it
is
really
important
to
start
metering
and
charging
for
for
the
actual
instructions
and
the
logic
that
actors
are
executing
apart
from
the
ciscos
themselves.
F
F
So
that
means
that
the
prices
that
are
currently
existing,
we
we're
not
introducing
any
changes
there
at
this
stage,
except
for
the
ipld
operations,
and
this
is
because
the
way
that
we
perform
iplt
state
management
operations
with
the
fvm
with
the
non-programmable
fvm
is
gonna
change,
so
we're
going
from
two
operations
which
were
the
ipld
get
and
the
ipld
put
into
five
into
five
operations.
So
these
are
a
block
open,
a
block,
a
block,
read
a
block
ride,
a
block
link
and
a
block
stat,
and
these
need
to
be
charged.
F
Specifically,
I
want
to
iterate.
I
want
to
emphasize
that
the
goal,
always
with
gas
model,
changes
and
kind
of,
like
the
policy
that
we're
taking
when
proposing
this
these
is
to
achieve
the
maximum
possible
execution
fidelity.
So
this
means
that
we
want
to
charge
for
the
cost
of
actually
actually
executing
this
logic,
whether
it's
inside
the
fem
or
inside
wasabland
or
outside
wasn't
land
via
cisco.
These
are
kind
of
like
the
the
two
major,
the
two
major
things
that
we're
introducing
in
in
febr032.
F
F
What
might
sound
counterintuitive
is
that
the
cost
for
a
simple
value
transfer
is
higher
than
the
dispatch
to
actor
code,
and
the
reason
for
this
is
because
the
the
the
value
transfer
is
managed
entirely
inside
the
fem,
where
it's
sorry
inside
the
inside
the
vm
itself,
whereas
the
dispatch
to
an
attra
is
kind
of
like
a
lightweight
operation
that
just
ends
up.
F
Invoking
and
routing
the
call
to
the
to
the
actor,
which
then
goes
on
to
do
it
its
logic
and
like
it
ends
up
getting
getting
priced
based
on
the
syscalls
that
it
does.
This
is
the
current
situation
in
the
with
the
with
the
fem,
the
cost
of
actually
dispatching
to
actors
is
going
to
be
higher,
and
this
is
because
we
need
to
create
the
invocation
container.
That
is
the
sandbox
for,
for
that
was
an
actor
to
run.
F
F
Now
these
are
kind
of
like
the
three
changes
that
that
are
necessary
to
back
the
technological
shift
from
the
current
vm
runtime
to
to
the
10vm
runtime
to
the
fdm
proper,
and
then
there
is
in
the
next
fit,
which
is
the
one.
That's
gonna
that
that
aligns
with
the
unlocking
of
user
programmability
on
the
fem
user.
Programmability
is
going
to
mean
that
is
going
to
introduce
a
new
set
of
features
and
a
new
set
of
system
tasks
can
create
deployment
of
actors,
loading
of
actors,
validation
of
actors.
F
There's
gonna
be
other
other
things
that
that
that
need
to
be
taken
care
of
here,
for
example,
accounting
for
memory,
expansion
for
cisco's
that
are
currently
unpriced
and
that
are
currently
free.
But
these
are
lightweight
syscalls
that
have
very
little
impact
and
they're
only
invoked
by
built-in
actors
right
now,
but
in
the
future
they
will
be
accessible
to
any
other
actor.
So
we
need
those
calls
will
need
to
be
priced
as
well.
F
All
of
those
changes
are
proposed
in
a
in
a
in
the
in
the
second
fifth
that
we
submitted
yesterday,
and
the
intention
of
this
fifth
is
to
is,
for
it
to
be
scheduled
on
a
subsequent
network,
upgrade
the
one:
that's
actually
gonna
introduce
user
programmability.
So
the
intention
with
opening
this
tip
now
is
to
to
have
it
kind
of
like
macerate
and
have
it
like
capture,
discussion
and
input.
As
of
now
for
a
lot
for
kind
of,
like
you
know,
leave
it.
F
Basically,
the
intention
is
to
leave
it
an
open
draft
state
so
that
we
can
we
can
continue
discussing
and
we
can
continue
enhancing
this
flip
as
we
as
we
develop
as
we
develop.
F
The
the
user
programmability
features
and
we
realize
like
exactly
how
things
are
gonna,
be
priced
and
like
what
is
the
actual
logic
and
what
is
the
actual
cost
of
implementing
that
that
logic
and
executing
that
logic,
so
that
we
can
define
a
pricing
policy
now
for
zero
zero
32
we're
currently
conducting
benchmarks
one
one
complexity
with
kind
of
like
you
know,
everything
related
to
gas.
F
Is
that
because
we're
because
using
this
policy
that
I
said
at
the
beginning,
which
is
hey,
we
want
to
match,
execute
like
the
goal
of
this?
Is
execution
fidelity.
So
we
want
to
match
the
actual
computational
and
resource
cost
of
these
operations
that
we're
pricing,
so
that
then
we
can.
We
can
price
them.
F
Unfortunately,
this
can
can
only
be
done
empirically,
so
so
right
now,
what
we're
doing
is
conducting
benchmarks
to
to
figure
out
what
the
right
parameters
and
the
right
use
for
the
for
the
pricing
formulas
are
going
to
be
for
zero
32,
but
the
logic
and
the
model
is
already
defined,
and
it's
pretty
much
definite.
F
So
this
is
a
fib
that
I
propose
we
review
very
quickly
and
that
we
move
to
an
accepted
state
and
to
and
at
that
point,
we'll
fill
in
the
details
that
I
absolutely
needed
to
for
for
a
lot
for
to
move
it
to
a
last
call
state.
This
has
been
needless
to
say
that
this
has
been
the
product
of
tons
of
discussions
that
we've
had
in
terms
of
iterations
and
brainstorming
and
approaches
and
things,
so
we
feel
pretty
confident
about
this.
F
This
direction
and
just
wanted
to
communicate
that
to
this
group,
there's
also
a
discussion
that
we
open
to
a
fib
discussion
that
we
open,
which
is
kind
of
like
the
placeholder
discussion
in
case
you're,
like
you
know,
have
thoughts
about
this
like
the
whole
architecture
and
kind
of
like
the
whole
model
that
is
being
proposed
here,
then
feel
free
to
to
post
them.
On
on
that
discussion
with
that
feel
free
to
to
voice
out
any
questions
that
you
may
have
happy
to
answer
them.
B
Do
we
have
a
sense
of
how
much
of
how
this
will
change
costs
yet
for
existing
messages?
Like
do?
I
know
if
my
proof
commit
sector
is
to
become
half
as
expensive,
twice
as
expensive
stay
the
same.
F
So
it's
gonna,
so
all
costs
this
is
specified
in
the
in
the
fit,
but
the
cost
of
all
operations
is
gonna
is
gonna
increase,
because
we're
now
gonna
start
accounting
for
the
actual
computational
cost
of
those
operations
which
was
previously
impossible
to
do.
That's
why
we
weren't
doing
it
so
it's
gonna,
so
the
costs
are
gonna
become
more
in
line
with,
with
with
the
actual
execution
footprint
of
every
cisco.
Some
says,
goals
will
will
will
increase
more
in
cost
than
others.
F
Sorry,
some
some
actuary
methods
will
increase
more
in
cost
than
others.
This
is
depending
on
the
actual
amount
of
logic
that
that
they
that
it
performed
we're
currently
performing
benchmarks
here
to
to
understand
exactly
how
the
cost
of
each
actor
method
is.
Gonna
is
gonna,
vary
and
we'll
post
some
some
details.
Once
we
have
those.
F
One
policy
that
we're
that
we're
adopting
here
as
well-
and
this
is
explained
in
the
fit
which
is
well.
How
do
we
actually
get
to
the
cost
numbers
here
right
from
what
we
call
execution
units?
What
what?
What
we
call
execution
units
which
are
like
the
way
that
we
meter-
and
we
we
we
kind
of
like
add
points
to
a
counter
based
on
like
how
much
how
many
wasn't
instructions
have
been
have
been
performed?
F
How
does
like
the
those
execution
units
translate
into
five
point
gas
which
is
kind
of,
like
you
know,
an
important
crypto
econ
variable
there?
This
is
currently
being
being
studied,
but
there
is
the
the
policy
and
kind
of
like
the
heuristic
is
explained
in
that
fib,
and
it
has
to
do
with
the
sizing
of
blocks
with
the
epoch
time
that
the
file
that
the
network
needs
to
maintain
the
win
rate
and
kind
of
like
the
duplication
rate
and
the
worst
case
scenario.
There.
A
That's
great
raul,
you
actually
preempted.
My
question
is
how
many
or
are
there
other
sort
of
ad
hoc
analyses
being
done
by
crypto,
econ
lab
or
others
that
you're
aware
of
that?
We
should
sort
of
wait
and
review.
Ultimately,
once
they're
published.
F
Yeah,
so
for
crypto
econ,
yes,
they're
reviewing
the
the
model.
As
far
as
I
know,
our
team
is
reviewing
that
the
both
fips,
which
defined
the
the
model
but
ultimately
they'll,
be
most
concerned
but
kind
of
like
it
would
become
a
lot
more
relevant
to
them.
Once
we
actually
have
the
final
parameters
and
we
have
a
final
proposal
for
for
the
parameters
themselves
and
we
know
exactly,
we
can
calculate
ahead
of
time
exactly
how
each
message
will
vary.
F
F
A
And
I
expect
you
don't
have
any
certainties
around
the
exact
timeline
for
completion
on
any
of
these
things
yet,
but
I'd
mentioned
in
a
github
post
somewhere,
which
I
can
find
if
you'd
like
to
that
we're
thinking.
Probably
mid-march
is
going
to
be
next
week.
Sometime,
it's
coming
up
quickly
is
going
to
be
when
we'd
like
to
start
thinking
about.
Putting
these
in
last
call.
A
F
Yeah,
so
the
content,
the
content,
so
the
content
for
zero
zero
thirty
is
finalized
with,
except
for
maybe
the
last
few
sections
same
goes
for
zero,
zero.
Thirty
one
there's
an
implementation
that
is
gonna,
be
finished
by
the
end
of
this
week
as
well.
F
So
like
that
will
help
kind
of
like
finalize,
you
know,
bring
more
confidence
to
the
actual
to
the
actual
body
of
the
fip
and
for
zero
zero
32
we're
we're
tentatively
aiming
to
have
the
gas
model
parameters
as
a
proposal
for
a
draft
proposal
for
the
actual
parameters
by
the
end
of
this
week
or
the
beginning
of
next
week.
So
I
think
it
like
once
we
have
all
of
that
it
will.
F
It
does
all
line
up
to
filling
in
the
gaps
of
these
three
fips
and
moving
them
to
last
call
by
next
week.
A
Thanks,
we
can
continue
to
think
on
this
as
we
get
closer
to
next
week
in
the
fdm
channel
on
slack.
So
if
anyone
wants
to
follow
along
you'll
see,
but
when
we
do
move
to
last
call,
you
should
know,
because
we
should
make
it
very,
very
obvious
that
we're
looking
for
community
input
in
sort
of
the
final
days
of
considering
these
prior
to
acceptance.
E
E
However,
this
flip
is
currently
being
brought
up,
because
without
yet
we
may
have
some
issue
with
like
the
beauty
actor,
where
it's
like
russ
code
side
of
disease,
you
should
may
explain
more
and
we're
still
not
assessing
the
impact,
and
you
know
how
much
work
or
this
costs
but
yeah.
I
just
want
to
give
everyone
an
overview.
First,
I
usually
want
to
take
over.
B
Good
thanks
quick,
so
I
realized
there's
some
folks
here
who
have
joined
the
who
you
know
newer
folks,
since
let's
say
q4
last
year,
but
fifth
27
is
a
relatively
simple
change,
that's
being
proposed
in
the
market
state.
There
is
a
deal
proposal
object
which
basically
is
the
kind
of
fundamental
unit
of
storage
deals
on
file
coin.
B
B
It's
yours
that
deal
is
currently
a
string
on
on
falcon
state
today
and
it
is
not
enforced
that
it
is
a
utf-8
string
and
there's
various
issues
associated
with
that,
which
is
why
this
pip
was
introduced
last
year
or
potentially
even
earlier
than
that
in
order
to
change
it
to
be
bytes,
and
then
people
can
store
whatever
bytes.
They
want.
B
The
reason
that
this
was
accepted
into
the
falcon
network
v14
upgrade
but
was
kind
of
dropped
at
the
last
minute,
because
we
realized
that
integration
was
going
to
be
fairly
complicated.
Not
the
migration
itself,
it's
very
easy
to
convert
string
to
strings
for
bytes,
obviously,
but
going
from
the
old
like.
Is
it
having
that
transition
happen
from
a
world
where
folks
are
signing
serializing
and
signing
strings
to
serializing
and
signing
bytes
doable?
B
Certainly,
but
it
was
not
something
that
we
we
entirely
overlooked
the
problem,
and
it
was
not
something
that
we
could
implement
in
the
last
minute.
So
now
that
this
flip
is
back
on
the
table
now
for
exactly
the
for
the
same
reason,
utf
so
rust
is
my
understanding
that
rust
essentially
say
for
us
requires
that
strings
be
utf-8,
encoded
and
now
that
we're
moving
to
built-in
actors,
it's
rust,
based
it
will
be
operating
through
the
svm.
B
The
need
would
have
to
become
to
use
unsafe
rust
if
we
left
this
as
a
string.
So
we
want
to
change
this
in
order
to
overall
avoid
hacks
in
our
in
our
super
in
in
the
code.
That's
that's
very
deeply,
embedded
in
the
system
and
just
overall
ensure
safety.
So
that's
why
this
flip
is
back
on
the
table.
The
difficulty
obviously
has
not
gone
away
magically
in
the
past
six
months,
so
stab
alien
has
a
new
proposal
that
complicates
the
flip
a
little
bit.
B
That
adds
a
little
bit
more
complexity
to
exactly
how
this
change
would
happen,
but
that
should
make
it
a
lot
more
feasible.
I
haven't
proportionately,
opened
the
discussion
or
added
opened
a
pr
with
summarizing
the
new
idea,
but
just
verbally,
the
idea
is
to
have
a
union
type
that
can
either
be
a
string
or
a
byte
that
serializes
accordingly.
B
So
this
way
folks
can
continue
to
use
the
label
field
as
a
string
if
they
want
to,
in
the
in
the
days
leading
up
to
the
upgrade
you
serialize
strings
in
the
days
after
you
can
continue
to
serialize
string
and
folks
that
want
to
move
the
bytes
can
do
so.
I
will
write
up
the
proposal.
There
will
still
be
some
integration
work
needed
in
file
point
node
implementations
as
well
as
market
implementations,
but
it
should
be
a
lot
easier
and,
more
importantly,
it
should
be.
B
It
should
mean
that
we'll
be
able
to
do
this
without
having
a
large
number
of
deals
fail
on
the
day
of
the
upgrade
or
large
number
of
messages,
land
on
jail,
unsuccessfully
or
something
something
highly
undesirable
like
that,
which
was
the
original
reason
for
be
scoping
it.
So
that's
the
that's
the
kind
of
summary
that
of
what's
going
on
I'll,
I'm
aiming
to
open
the
new
proposal
that
that
should
make
this
more
feasible
by
the
end
of
the
week
and
yeah.
B
Hopefully,
we
can
consider
it
for
v16
and
avoid
any
hacks
in
the
fbm
and
in
the
new
built
in
actors.
E
Once
I
want
to
add
I'll
use,
the
fifth
has
been
open,
say
like
six
months
ago
and
the
main
results
like
drop
it
out.
Last
time
I
said
you
said
yes
about
the
ecosystem
impact,
basically
not
just
like
the
implementation
integration,
but
also
the
applications
that
is
building
on
top
of
file
coin,
that
helping
users
to
make
deals.
The
impact
will
be
there.
So
that's
the
most
concern
is
so
I
want
to
you
know,
cut
this
out
to
the
ecosystem.
E
Application
like
builders,
take
a
look
at
the
fit
and
see
like
understand
it
and
see
if
you
can
adapt
yet
like
as
soon
as
possible,
so
that,
like
you,
have
a
smooth
transition
when
this
php
is
actually
finalized
in
the
network.
B
Yes,
agree
with
that,
plus
one
and
there's
a
few
things.
Implementations
like
lotus
can
do
to
try
to
mask
the
change.
That's
happening
as
much
as
possible,
especially
for
valid
utf-8
strings.
But
yes,
that's
a
for
anyone.
Who's
building
kind
of
storage
applications
should
would
definitely
want
to
pay
attention
to
this,
and
please
let
us
know
if
you
foresee
problems
in
chat
raul
asks.
How
would
this
migration
look
with
the
with
this
new
approach?
B
Are
valid
utf-8
strings
kept,
as
is,
and
invalid
ones
migrated
to
the
bytes
representation.
That's
actually
an
open
question,
so
invalid
ones
are
definitely
and
we
can
adopt
one
or
the
other
approach.
Invalid
ones
will
definitely
be
migrated
to
the
bytes
representation,
whether
we
also
want
to
val
migrate,
valid
utf-8
strings
to
bytes
or
leave
them.
As
is
an
open
question.
I
think
we
I'm
initially
the
the
momentum
was
towards
migrating
everything
to
bytes,
but
maybe
just
for
the
reason
that
jennifer
just
mentioned
for
minimizing
any
ecosystem
turbulence.
C
Yeah,
I
don't
personally
have
any
thoughts
at
the
moment.
I
think
a
lot
of
information
and
I
just
want
to
observe
a
little
bit
more,
I'm
not
sure
if
rest
of
the
development
or
engineering
team
has
any
questions
or
anything
at
the
moment,
yeah
nothing
on
mine.
A
All
right
and
ayush
has
an
aside
to.
I
will
share
once
you're
able
to
push
sort
of
the
newly
proposed
changes
formally
into
the
repo
I'll
share
it
with
the
builders
channel
too,
and
talk
to
some
of
the
developer
advocates
that
work
in
the
filecoin
network
to
see
if
they
can
kind
of
share
it
with
those
they
know
who
are
specifically
working
on
like
storage
applications.
A
A
We
can
do
these
things
in
tandem,
which
makes
it
easier
for
everyone,
I
think,
to
understand
sort
of
the
chain
of
events.
But
do
you
know
like
every
other
fifth,
we
are
still
and
always
looking
for
feedback
and
putting
ideas.
So
everyone,
if
you
haven't,
especially
in
quite
a
while
please
do
take
a
look
at
the
proposes
that
ayush
pushes,
as
well
as
the
existing
fifth
draft,
which
is
merged
already.
B
Thank
you,
caitlyn,
and
the
nice
thing
about
this
fip
is
in
response
to
feedback
that
we
do
get
especially
from
folks
in
something
like
the
builders
channel
of
the
folks
that
they
talk
to
is.
We
can
try
to
make
changes
not
in
the
fitbit
sales,
but
in
the
clients,
where
it's
always
easier
to
make
changes
to.
You
know,
accommodate
any
problems
or
alleviate
any
pains
that
folks,
any
pain
points
would
folks
raise.
B
So
we're
definitely
interested
in
that
feedback,
and
we
can
action
on
it
to
make
things
as
simple
as
possible.
Great.
A
And
as
a
reminder,
too,
it
is
important
that
core
devs
make
the
final
determination
as
to
which
fits
they
would
like
to
incorporate
in
each
network
upgrade.
So
I
will
update
our
ongoing
discussion
post
related
to
this
upgrade,
in
particular
after
the
call
today
incorporating
fifth
27
is
a
fip
we
are
proposing
to
implement,
as
well
as
the
upgraded
timeline
which
we
will
consider
confirmed
I'll.
Add
a
link
to
the
test
plan
which
jennifer
so
kindly
has
put
together
for
us
and
the
last
thing
other
than
this.
A
Then,
of
course,
is
the
very
important
question
of
what
we
call
the
v16
upgrade.
We've
had
a
very
fervent
conversation
about
this.
I
also
informally
pulled
the
file
coin
foundation,
just
to
know
what
everyone
thought
it
looks
like
the
name.
Skyr
is
the
leader.
A
So
if
anybody
has
any
issues
or
questions
of
this
being
the
name
or
feels
very
strongly,
it
should
be
something
else.
Please
let
us
know.
Otherwise
we
will
move
towards
considering
this
confirmed
also.
A
So
the
other
thing
we
were
going
to
talk
about
today,
I
know
we're
almost
the
time
was
an
introduction
of
preliminary
planning
for
b17.
Don't
want
everyone
to
be
overwhelmed
as
we
prepare
for
yet
another
big
upgrade
in
b16.
A
A
If
you
have
not
reviewed
them
either
in
the
discussion
posts
or
the
actual
flip
drafts
themselves,
I
would
highly
recommend
putting
some
time
aside
to
look
through
them.
The
proposals
are
already
quite
thorough.
We
do
want
to
make
sure
that
everyone
has
had
ample
time
to
review,
formulate
questions
and
bring
them
back
to
the
group.
But
again
the
best
person
to
walk
us
through
this
would
be
alex
north
himself.
A
So
what
I'd
recommend
everyone
do
if
possible
and
as
always,
I
will
flag
this,
for
you
is
watch
the
recording
from
the
second
for
devs
call
if
you
are
not
planning
to
attend
or
additionally
do
review
the
notes
from
the
session
when
they
are
published,
because
it
will
include
again
all
of
the
information
that
alex
was
able
to
present
in
the
second
meeting
later
this
afternoon.
E
I
did
the
slide
just
to
edit
a
note.
Is
those
flips,
like
our
amazing,
we
said
like
likely.
We
want
to
do
those
for
network
v17.
However,
we
still
want
to
discuss
it
with
we're,
seeing
the
core
that's
on
what
the
scope
of
network
v17
should
be.
Should
we
be
shipping
if
vmm2
as
like
a
main
focus
across
all
the
teams,
or
should
we
actually
be
working
on
this?
E
You
know
pre-user
program
use
a
programmable
fpm
network,
like
readiness
sort
of
the
things,
because
it's
like
a
chicken
like
issues
it's
like,
should
we
enable
the
program
ability
first
or
should
we
make
sure
you
know
things
are
ready
and
before
we
actually
officially
do
the
big
like
lunches.
E
I
try
to
have
the
open
questions
listed
here,
so
so
yeah
everyone,
please
take
a
look
and
check
me
in
the
tpm
forum
and
see
like
what's
your
source
are
because
both
will
require
some
level
of
in,
like
you
know,
implementation
work
and
if
evm
team
can
potentially
use
our
support
on
shipping
as
well.
So
that's
a
tricky
decision
to
make.
A
Yeah
and
in
parallels
you're
thinking
about
these
questions
just
to
flag
the
discussion
that
we've
been
having.
Thank
you
to
ayush
for
opening
this
thread.
Topic
is
really
how
big
should
a
network
upgrade
be
so
the
v16
upgrade
is
going
to
be
quite
large.
It's
going
to
represent
a
significant
change
to
the
structure
and
operability
of
the
network.
A
It's
going
to
require
a
lot
of
work
for
all
of
you
when
we
think
about
sort
of
what
follows
that,
how
many
fips
do
we
want
to
consider
and
what
are
the
scope
of
those
steps?
A
How
should
we
think
about
this
from
both
a
capacity
perspective
within
your
teams,
but
also
to
when
we
think
about
engendering
the
security
of
the
network,
making
sure
it
remains
resilient
testing
remains
thorough
and
that
we
really
have
the
capacity
to
onboard
community
members,
as
these
changes
occur,
are
all
important
things
to
keep
front
of
mind
as
well.
C
I
have
one
question
or
comment
here,
so
the
timeline
so
v16
is
getting
executed
in
may
and
then
right
after
a
month,
we
are
executing
v
17.
Is
that
enough
time
to
see
if
everything
is
working
properly
with
the
v16
network-
and
you
know,
and
all
the
nodes
across
various
are
stable
as
well
as
if
testings
are
done
properly,
because
the
timeline
seems
to
be
very
short,
in
my
opinion,
between
the
network
upgrades
here,
I'm
not
sure
how
others
feel
about
it.
I
might
be
off.
B
B
Yeah,
I
think
whether
or
not
the
16,
the
fbm
and
so
on,
can
it
did
its
job
and
is
correct,
will
will
be
evident
fairly
clearly
fairly
immediately.
So
that
part,
I'm
not
I'm
personally,
not
too
concerned
about
raul.
Maybe
you
can
speak
to
it
more
sorry.
What
was
the
question?
B
It's
essentially
if
this
is
the
timeline
that
we're
adopting
for
v17?
Do
we
think
it's
been
essentially?
Do
you
think
it's
been
long
enough
since
the
fm
came
live
that
we're
confident
enough
in
the
stuff
that
we
introduced
in
v16
that
we
can
consider
doing
new
things,
or
do
we
just
want
to
let
b16
stew
for
longer
to
make
sure
everything
is
working.
F
So
I
I
don't
think
one
thing
is
related
to
another
honestly
as
soon
as
like
as
soon
as
v16
goes
live,
and
as
soon
as
that,
like
usually
the
time
between
network
upgrades,
is
enough
to
verify
that
a
the
previous
network
upgrade
is
operating
as
in
as
as
intended.
F
I
don't,
I
don't
think
it
has.
It
has
any
any
impact
or
there's
any
information
between
one
thing
and
another.
E
Yeah,
oh
I'm
sorry.
I.
B
F
That
sounds
like
like
a
question
about
implementation
of
nv17,
more
than
the
lining
up
and
kind
of
like
the
space
between
one
upgrade
and
another
right,
it's
more
like.
Can
we
get
nv17
implemented
in
the
amount
of
time
in
the
short
amount
of
space
in
the
short
amount
of
time,
with
all
the
assurances
that
the
network
needs
that
it's
quality
tested,
I
think.
E
We
should
discuss
at
the
later
part,
like
apparently
a
used
focus
part
on
the
v17,
maybe
in
two
weeks
again
after
we
know
the
scope
on
that
like
because
again
the
scope
decides
the
timeline,
but
I
do
want.
I
do
agree
with
yeah.
I
think
that's
a
very
good
flag,
because
fvm
is
a
big
change
to
the
network.
We
have
like
you
guys,
models
and
stuff
like
that.
The
core
devs
like
we
should
come
up
a
checklist
basically
saying
like
you
know,
after
a
network
v17
60
is
like
live
in
the
network.
E
These
are
the
matrix
that
we
should
be
tracking
and
monitoring
and,
like
make
sure
they're
all
going
well.
You
know
we
should
not
launch
another
big
network
upgrade
without
like
checking
off
all
those
like.
You
know,
boxes
which
I
think
makes
sense,
and
you
know
if
anything
needs
to
be
fixed.
We
should
be
considering
that
as
well.
A
So
again,
as
always,
we'll
continue
to
talk
about
this
to
jennifer's
specific
point.
In
two
weeks,
we
can
bring
this
conversation
up
again
with
greater
specifics
as
well
and
dedicate
more
time
to
really
making
sure
that
teams
have
enough
time
for
testing
as
well
as
feeling
confident
about
being
able
to
implement
on
me
now.
A
As
always,
everything
will
be
updated
after
this
meeting
on
our
separate
tpm
discussion
forums,
flagging
all
of
the
links
and
meeting
notes
and
again
just
to
reiterate,
as
we
move
to
this
new
structure
for
the
core
devs
call
if
you
are
unable
or
not
planning
to
join
this
afternoon's.
Second
call:
please
do
check
meeting
notes
after
the
fact
that
you
can
find
the
presentation
on
these
proposed
fips
from
alex
north
himself.
A
All
right,
as
always
thanks
so
much
for
taking
the
time
participating,
it's
always
great
to
see
everyone
on
this
call
any
last
minute,
questions
or
thoughts
that
arise
to
you
afterwards
feel
free
to
message
me,
and
otherwise
I
will
see
you
all
for
meeting
39
in
two
weeks.