►
From YouTube: Filecoin Core Devs Biweekly #15
Description
Recording for: https://github.com/filecoin-project/tpm/issues/34
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
Think
all
right,
good
morning,
good
afternoon,
everyone
welcome
to
the
15th
of
the
falcon
core
devs
meetings.
Today
is
the
eighth
of
april.
I'm
gonna
drop
the
issue.
The
agenda
cool
yeah
agenda
for
today
is
kind
of
our
usual
usual
updates
from
all
the
various
teams
in
the
foundation
and
so
on.
We'll
do
we're
gonna
talk
about
what's
going
into
the
next
network,
upgrade
so
not
the
one
happening
in
about
four
days,
but
the
one
that
we're
thinking
will
happen
sometime
in
june.
A
So
we
just
need
to
start
to
start
deciding.
You
know,
what's
in
scope,
what's
out
of
scope
and
also
I
had
some
conversations
around
how
the
other
implementations
can
can
leverage
the
filecoin
community
to
test,
and
so
we
we
can
have
a
conversation
around
kind
of
like
community
testing
and
beta
users,
and
so
on
of
the
newer
implementations,
which
will
be
cool
yeah.
Who
wants
to
kick
off
updates
forest
video.
B
So
a
couple
of
things
that
we've
been
focusing
on
are
the
message
pool
and
mainly
actually
focusing
on
syncing.
So
we've
already
made
lots
of
great
improvements
that
I'll.
Let
eric
talk
about
in
more
detail
soon,
but
we're
just
focusing
on
improving
this
and
by
creating
a
more
robust
sinking
state
machine.
B
B
Otherwise,
we
are
also
working
on
integrating
the
storage
and
retrieval
markets,
the
go,
fill
markets,
module
and
so
we're
doing
that
by
updating
our
pay
channels,
implementation
and
then
we'll
have
to
add
the
rpc
methods
for
that
and
yeah.
Otherwise,
we
are
also
hoping
to
get
some
instrumentation
done
prior
to
the
audit,
and
so
currently
we
are
thinking
of
using
grafana
and
prometheus,
but
yeah
we're
still
kind
of
designing
that
and
yeah.
C
Yeah
yeah,
I
can
speak
a
little
bit
to
that,
but
yeah
for,
like
you
know
the
past
few
weeks
we've
been
kind
of
trying
to
chase
down
exactly
where
we
were
slow
in
the
vm,
and
because
I
mean
I
guess
there
was.
We
didn't
really
have
a
good
reference
for
like
how
fast
the
other
implementations
were
with
respect
to
vm
execution,
like
primarily
like
executing
messages
and
the
cron
actor
stuff.
C
So
it
looked
like
we
were
quite
a
bit
slower
compared
to
lotus
before,
and
that
was
because
the
thing
was
what
I
was
measuring
on
lotus
was
actually
how
long
it
takes
for
a
worker
to
process
like
blocks
coming
in
through
gossip
sub,
and
so,
like
you
know
like
normally.
What
would
happen
is
like
you,
get
a
block
during
some
epoch
and
then,
like
the
previous
tip,
sets
messages
and
all
the
crown
stuff
gets
executed.
C
However,
it
turns
out
in
lotus
some
of
the
stuff
gets
optimistically
computed.
I
learned
this
from
magic
yesterday,
but
some
of
the
stuff
gets
optimistically
computed
due
to
a
like
some
quirk
in
the
message
pool
where
it
needs
to
where
it
calculates
the
tips
at
state
for
the
current
epoch,
thus
calculating
its
parents
stuff.
C
So
that
was
kind
of
interesting,
but
we
we
did
make
a
lot
of
optimizations
on
the
way
anyways,
which
turned
out
to
be
pretty
good,
so
yeah,
that's
kind
of
like
our
updates
for,
like
the
vm
performance
related
to
syncing
and
then
yeah
with
with
respect
to
like
our
actual
like
chain.
Syncing
algorithm
jorge
here,
has
been
working
on
kind
of
refactoring
it
to
make
it
a
more
robust,
like
state
machine.
A
C
Hasn't
it
hasn't
landed
yet,
but
we've
made
pretty
good
progress.
I
mean
our
syncing
algorithm
currently
works
like
okay,
but
I
think
there's
like
quite
a
bit
of
quite
a
bit
of
room
for
improvement,
which
is
why
we
kind
of
want
to
do
this
refactor.
But
you
know
if
we
don't
get
this
one
in
on
time,
for
the
audit
like
we
can
default
to
what
we
have
right
now,
which
you
know
syncs
the
tip
set
in
like
two
seconds
at
this
point
so
which
is
pretty
good.
B
B
His
recommendation
was
to
kind
of
do
as
much
as
we
could
with
the
syncing,
because,
like
changing
that
in
the
future
might
mean
a
full
like
re-audit,
because
it
touches
so
many
different
parts
of
the
code.
So
we
are
it
is.
It
is
definitely
late
in
the
game,
but
we're
trying
to
get
it
in
so
that
we
can
make
best
use
of
of
the
audit.
Essentially,
that
makes
sense.
A
E
Okay,
yeah
sorry
yeah
good
morning,
everyone
and
good
evening
and
for
villas
and
with
us
implementation.
We
are
still
working
on
the
distributed
media
pools
port.
So
we
have
a
different
component
and
development
on
the
way
and
the
plan
is
that
we
will
have
all
the
components
integration
together
and
to
deploy
them
and
all
of
them
on
the
main
network
to
upgrade
the
current
vls
load
and
support.
E
E
E
We
have,
we
will
have
one
release,
we
call
it
0.9.4
in
the
plan
to
release
within
one
week,
and
it
will
also
support
the
digital
conversion,
11
and
yeah,
to
upgrade
and
to
yeah
to
the
main
network
to
support
which
is
coming
soon.
Yes,
that's
what
was
it?
Okay,
that's
more!
You
know.
One
more
thing
is
about.
Well
still
is
audit
progress.
We
yeah
the
plan
to
have
the
first
support.
I
wasn't
in
10
days,
which
goes
mostly
yeah.
Okay,
I
think
that's
all.
A
No,
that
sounds
good.
I
noticed
the
post
in
still
lobby
yesterday
asking
people
to
that
that
venus
notes
can
be.
Can
we
run
on
main
that's
exciting
and
I
think
yeah,
I
think
the
distributed
mining
pool
work
is,
is
going
to
be
probably
really
welcomed
by
a
good
chunk
of
the
mining
community.
So
it's
really
good
to
happen,
and
it's
really
cool
that,
like
lotus
and
venus
will
be
able
to
kind
of
like
share
in
in
such
a
pool,
so
good
work,
cool,
fujong,
realtor
updates.
F
Good
morning
or
evening,
everyone
so
for
fun
for
fujon
we
are
focusing
for
the
the
on
fixing
all
the
issues
that
are
blocking
us
from
the
going
to
the
main
net
and
basically
releasing
the
node
since
the
last
meetings.
Well,
on
the
last
meeting
I
mentioned
that
we
had
the
major
memory
leak
which
was
resolved,
but
then
we
found
another
one.
The
previous
one
was
on
the
repeat:
piece
site
and
introduced.
F
Introduction
of
democracy
factoring
has
fixed
all
the
well
previous
issues,
issues
on
this
side,
so
the
current
one
we
actually
haven't
identified
it
like
precisely.
We
know
for
sure
that
it's
only
not
only
put
to
be
leap
to
b
side,
so
it's
probably
somewhere
on
fujon
side,
and
we
are
trying
currently
trying
to
introduce
changes
that
probably
will
fix
the
issue.
If
not,
then
we'll
have
to
do
some
more
research
on
the
root
cause.
F
F
Issues,
probably
in
the
virtual
machine
again,
this
is
something
that
we
have
to
reconfirm
as
we
have
introduced
the
possible
fix
and
we
just
need
to
verify
that
it
is
fixed
and
the
third
third
one
is
actually
the
hardest
to
catch.
So
we
have
an
error
which
is
thrown
by
some
some
of
our
libraries,
not
the
main
code
from
the
fuchon
oli
p2p.
F
So
we
have
to
trace
it
to
the
exact
place
on.
Basically,
what
is
happening
on
the
underlying
libraries
and
it's
kind
of
hard
to
do
as
the
issue
itself
is
kind
of
rare
and
we
are
not
able
to
reliably
reproduce
it,
so
we
are
just
starting
with
the
mainnet
node
and
waiting
for
it
to
happen.
So
this
is
kind
of
like
the
worst
case
bug
you
can
imagine,
but
there
is
nothing
actually
we
can
do
about
it,
so
we
will
try
to
find
the
root
cause
and
fix
it
as
soon
as
possible.
F
So
this
is
our
status
as
for
today,
as
for
the
different
things
we
are
doing
is
we
are
still
working
on
introducing
our
own
actors,
so
we
are
working
on
the
last
one
still,
which
is
storage,
minor
actor
p2
and
after
that
we'll
have.
We
will
start
on
storage
while
on
actors
v3
so,
but
this
is
planned
for
versions
either
1.1
or
1.2.
A
A
So
there's
a
mysterious
error
that
says
no
error.
I
can
imagine
not
gonna
figure
out
after
that.
We
are
cool,
though
exciting,
that
you
know
the
list
of
the
list
of
things
that
are
actually
kind
of
like
blocking
production
ready
is,
is
fairly
small
by
this
point,
which
is
great
cool
all
right
from
the
from
the
lotus
side
of
things
not
not
too
much
happening.
On
our
end,
mostly
like
last
couple
of
weeks,
work
was
around
the
upcoming
network,
v11
upgrade
so
we
ran.
A
A
So
far,
it's
a
very,
very
small
release
so
hoping
that,
hoping
that
there
won't
be
any
issues
with
that,
apart
from
that
kind
of
the
two
major
threads
on
our
end
are
a
lot
of
work
on
kind
of
internal
improvements,
so
how
how
to
ship
releases
better,
how
the
test
releases
better?
How
to
handle
emergency
situations
better
and
we'll
be
talking
about
this.
A
Some
more
we're
basically
trying
to
yeah
try
trying
to
ship
better
software
and
build
trust
in
in
new
lotus
releases,
because
there's
a
bit
of
a
burst
of
that
in
the
community
right
now
which
which
we've
earned
so
so
a
lot
of
focus.
On
that
I
mentioned
the
release
issue
template
that
we
that
were
that's
under
construction
in
the
last
call
feel
free
to
check
it
out
and
share
any
feedback
if
you
have
yeah.
So
that's
kind
of
one
thread
that's
happening.
A
The
other
thread
is
scoping.
Everything
that's
needed
for
the
next
network,
upgrade
so,
and
that's
kind
of
cross
team
work
that
there's
work
happening
in
proofs.
There's
work
happening
in
actors
and
lotus
has
to
integrate
at
least
trip
13.
The
group's
application
changes.
So
that's
kind
of
all
happening
at
the
same
time
and
will
be
one
of
the
things
we
talked
about.
A
A
Nice
maxim
says
that
he
has
to
go,
but
alexa
is
staying
behind
yeah,
it's
good
to
have
more
implementations
around
these
upgrades,
especially
when
they're
smaller
ones,
so
they're
kind
of
easier
to
to
see
if
everything
works.
Well,
that's
cool!
All
right!
I
put
it
in
the
agenda
this
time
because
I
didn't
want
to
keep
forgetting
any
updates
from
the
falcon
foundation
that
you
folks
would
like
to
share
with
us.
H
No
really
big
updates
on
our
side
yeah.
We
have
no
updates,
but
we,
you
know,
making
an
update
on
the
chain
save.
In
summary,
we
have
contracts
ongoing.
We
have
some
bdf
work,
that's
ongoing.
So
if
you
guys
want
to
hear
more
about
that
happy
to
update
but
we've
otherwise,
you
know
we
gave
a
10
million
dollar
donation
to
internet
archive
last
week,
if
you
guys
saw
so
it's
a
couple
of
exciting
things.
A
I
Sorry,
I
actually
have
a
update
update,
so
we
actually
launched
the
file
koi
ambassador
program.
It's
a
pirate
program.
That's
gonna
start
kickoff,
like
maybe
next
week,
we're
just
like
picking
our
first
cohort,
so
they're
gonna
help
with
our
like
community
moderation,
community
management
and
community
engagement
for
like
onboarding
miners
developers
and
clients.
So
if
any
other
implementation
that
needs
any
help
or
is
the
community
there,
let
us
know-
and
we
got
a
group
of
people
that
can
help
us
now.
H
I
A
So
so
so
the
case
would
ideally
be
as
more
implementations
join
and
get
popular
that
in
the
community
ambassadors
program
we
have
people
that
are
capable
of
supporting
other
implementations
familiar
with
the
other
implementation
service
ambassadors,
for
that
makes
sense,
cool
sounds
good.
All
right,
yeah
next
next
item
that
I
have
in
the
agenda
is
just
scoping
out:
network,
v12
actors,
b4
and
everything
to
go
into
that.
So
why
I
will
let
you
take
over
here.
G
Great,
so
I
just
posted
a
link
to
this
issue
in
the
zoom
chat,
so
I've
been
spending
a
bit
of
time
thinking
about
what's
going
to
go
in
actors
v4-
and
I
guess
the
first
thing
to
talk
about
is
the
timeline.
It
still
feels
a
bit
vague.
I've
heard
like
early
june,
like
as
rough
consensus
from
pl,
and
so
that's
what
I'm
working
with.
I
don't
have
an
exact
date.
I
don't
expect
we'll
have
an
exact
date,
and
also
I
mean
this
is
something
that's
you
know
somewhat
up
for
discussion
here
too.
G
G
The
most
important
five
things
are
under
the
the
upgrades
and
conformance
testing
sections,
so
yeah
I'll
actually
just
go
through
the
things
that
I
think
need
to
be
in
v4,
meaning
that
if
we
don't
have
them,
we
we
don't
ship
the
release,
and
so
the
most
important
of
these
is
fifth
13
with
aggregate
prorep.
It's
also
the
most
work
and
it's
shared
by
everyone.
G
Then
there's
also
two
simple:
fips,
the
verified,
client,
reuse,
consensus,
fault,
simplification
and
then
there's
a
bug
fix
too,
and
the
site's
like
for
code
that
all
actors,
implementations
will
need
to
write
and
then
on
the
conformance
testing
side.
This
is
mostly
work
for
the
specs
actives
team,
not
for
other
actors
teams.
Although
the
other
implementation
teams
you'll
need
to
be
able
to
consume
these,
but
I
think
that
shouldn't
be
a
problem.
This
should
be
more
of
a
benefit
than
a
kind
of
cost
for
everyone
else
here
and
that's
yes.
G
On
the
conformance
testing
side,
I'm
saying
we
won't
ship
v4
until
spectaculars
can
generate
a
good
set
of
conformance
tests
in
the
form
of
test
vectors,
which
can
then
be
consumed
by
external
implementations.
To
get
us
better,
more
automated
convergence
to
ensure
the
conformance
happens,
so
I
can
talk
about
any
of
these
things
more,
I
think
the
biggest
so
yeah.
G
There
are
other
things
in
this
that
we
can
get
into
a
lot
of
it's
like
optimistic
work
that
I'm
saying
we
we
can't
include,
and
we
should
work
on,
but
it
doesn't
need
to
be
there.
I
think
the
the
most
important
thing
is:
I'm
not
sure
if
this
happens
now
or
in
the
next
few
weeks,
but
the
most
important
thing
is
to
to
get
buy-in
from
you
all
of
the
other
implementations
on
on
this
feature
set
by
early
june,
yeah
to
figure
out
now,
if
it
seems
achievable.
G
Yeah
thanks
yeah.
I
should
link
to
the
prs
too
so
11
and
12
are
merged,
so
spec
actors
has
these
13
is
in
a
draft
state.
It
is,
it
is
functionally
there.
It
hasn't
been.
You
know,
fully
optimized
or
fully
security
analyzed,
but
the
bulk
of
the
code
that
I
expect
to
be
there
is
there.
So
it's
it's
in
a
decent
state,
I'm
hoping
end
of
week
next
week
that
that's
like
fully
merged
and
good.
The
the
final
of
the
of
the
like
blocking
upgrade
work,
the
the
partitioned
compaction
bug.
G
C
You,
I
guess
I
have
one
other
question,
not
not
exactly
related
to
this,
but
in
general,
but
well.
What
are
the?
Who?
Who
are
the
kind
of
like
stakeholders
involved
in
deciding
when
these
network
upgrades
happen?
Because
yeah
I
mean
zen
just
mentioned
that
pl
but
like
who?
Who
is
pl
because
I
mean
surely
spec
actors
is
pl.
G
G
I
guess
somali
would
be
kind
of
a
point
of
contact,
that's
kind
of
who
I'm
I'm
talking
to
right
now
or
who
I
need
to
talk
to
right
now
about
about
making
this
more
solid.
I
think
this
date
is.
I
can't
really
point
to
a
single
person
right
now.
Who's
set
this
date,
which,
which
seems
like
a
bit
of
a
problem
in
itself.
It
seems
like,
like
I
use
magic
like
the
fight,
the
so-called
file
coin.
G
Stewards
team,
like
including
myself,
we've
all
kind
of
been
like
there's
this
rough
estimate
of
like
three
months
or
two
like
two
to
three
months
between
upgrades
and
so
we've
been
like.
I
don't
know
this
number
has
come
out
of
that,
or
this
date
has
come
from
that
there
isn't
a
great
formal
process
of
of
setting
the
state
and
yeah
we
also
haven't.
G
It
seems
like
we
haven't.
You
know
consulted
with
with
you
guys
or
with
other
implementations,
about
feasibility,
yeah,
so
yeah.
Maybe
this
is
the
time
to
to
figure
out
how
we
do
this,
how
we
set
timelines,
because
you
know,
I
think
eventually
it
has
to
be
like-
maybe
right
now,
it
makes
sense,
for
you
know
the
pl
specs
actors
team
to
be
to
be
driving
timelines
and
trying
to
like
set
deadlines.
G
A
Yeah
so
lots
of
thoughts
there.
I
think
we're
already
past
the
point
where
pl
or
any
kind
of
like
single
representative
of
pl
is
shaping
timelines.
I
don't
think
I
I,
I
think,
we're
yeah
we're
kind
of
already
past
that,
just
because
we
have
other
implementations
on
mainnet
already
so
india
in
terms
of
how
we
make
in
terms
of
who
makes
a
decision.
A
The
answer
is
fairly
simple,
and
that
is
basically
this
group
of
people
achieving
consensus
on
around
some
timeline
in
terms
of
how,
but
obviously
we
need
to
be.
We
need
to
be
factoring
in
kind
of
the
community
and
the
network,
as
opposed
to
you
know
what
works
for
us
so
that'll
be
stuff
like
you
know
what
what
miners
want?
What
storage
clients
want?
A
Is
there
a
critical
bug
that
we
want
to
get
fixed
and
that
kind
of
thing
with
this
particular
network
upgrade
like
I
think,
fib
13,
the
proof's
aggregation
ship
is
a
kind
of
like
universally
good
thing
that
we
want
to
get
out
into
the
network,
because
it
really
is
kind
of
like
transformative
to
how
much
can
happen
on
the
pipeline
network.
So
that's
kind
of
what's
keeping
the
timeline
a
little
a
little
more
aggressive,
but
yeah.
A
So
I
don't
I
don't
so
I
think-
and
ideally
you
know
more
and
more
of
this
moves
away
from
the
pl
side
of
things
and
becomes
becomes
a
consensus
decision
that's
reached
and
I
think
we're
moving
the
right
direction
there.
That
does
mean
that
a
lot
it'll
always
be
a
somewhat
messy
process
if
it
feels
like
we
have,
but
it
feels
like
we
haven't
picked
a
timeline
for
b12
upgrade
slash
b
for
actors.
A
We
have
to
achieve
consensus
or
worst
case
we
come
to
a
place
where
you
know
one
implementation
doesn't
support
an
upgrade
for
some
reason
or
the
other,
but
that'll
be
that'll,
be
a
fairly
tricky
thing
to
have
to
have
negotiate.
So
I
think,
from
my
perspective,
short
answer
is
yeah.
I
definitely
don't
think
it's
any
any
single
person
or
group
of
people
at
pl.
A
I
think
the
final
answer
is
from
the
group
of
people
here
weighing
in
opinions
from
everyone
from
the
community
from
for
minors
from
folks
at
pl
from
everyone
else,
but
but
yeah.
Ultimately,
the
decision
is
being
made
here
and
I
think
that's
kind
of
what
we've
done
with
with
v4,
which
is
which
is
good,
but
I'm
very
interested
in
hearing
what
everyone
else
has
to
say
on
this.
E
Austin,
it's
good
to
have
you
have
a
group
here
to
have
a
decision,
but
businesses
and
everything
everyone
in
this
meeting
or
and
everyone
in
the
community
can
have
some
comments
or
suggestion
or
yeah
advice
or
something
like
this.
But
we
still
need
someone
to
yeah
to
have
they
file
a
proposal
and
yeah.
We
need
to
have
one
to
come
up
with
a
schedule
or
proposal,
so
it
looks
like
we
need
yeah,
for
example.
E
If
we
have
the
pace,
we
have
the
definition
to
have
one
release
every
two
months
or
three
months,
and
then
we
could
define
upper
back
manager
on
that
yeah.
I
believe
right
now.
Yeah
molly
is
a
product
manager.
We
we
have
this
one
to
be
responsible
to
come
up
and
are
yeah
an
attitude
of,
and
just
at
least
and
to
to
get
all
the
proposals
or
yeah
or
comments
or
review
from
and
everybody.
E
E
Yeah
this
yeah
in
this
issue-
east
yeah,
but
when
we
have
having
a
release,
we
still
need
a
little
bit
and
detailed
and
your
planning,
for
example,
when
we'll
have
all
these
features
done
in
yeah
from
the
implementation
point
of
view,
and
we
still
have
other
components
in
other
implementations
to
have
all
this
yeah
workable
and
we
need
to
have
the
testing.
So
we
need
to
have
defined
the
different
timeline
right.
So
essence,
yeah.
G
A
Yeah
I
like
that
idea
a
lot,
and
I
think
I
I
think
that's
kind
of
the
right
way
to
be
thinking
about
this
is
yeah
like
so
and
potentially
that
one
person
could
be
like
a
pl
person,
quote-unquote
who's,
basically
doing
the
organization.
Work
is
basically
like
kind
of
sourcing,
all
the
input
and
aggregating
it
in
one
place
and
then
being
like
here's.
A
What
we
need
to
be
discussing
and
essentially
preparing
the
decision
that
needs
to
be
made,
but
ultimately
the
decision
that
itself
should
be
made
yeah,
I
think,
by
this
group
of
people,
and
ideally
we
do
it
transparently,
like
maybe
in
an
open
slack
channel
or
in
these
recordings
works
well
too.
Yeah.
I'm
also
curious
to
hear
foundation
folks.
If
what
y'all
think
about
this,
just
from
the
principle
of
you
know,
moving
moving
governance
away
from
any
one
large
organization
or
group
of
people.
H
A
C
Yeah,
I
was
just
going
to
say,
like
I
think,
we're
pretty
our
process
on
deciding
which
fips
kind
of
get
accepted
are
pretty
good
but
yeah.
I
guess
the
the
point
that
I
was
trying
to
nail
down
is,
you
know,
like
I,
don't
think
the
community
should
kind
of
decide
when
we
should
be
implementing
things
in
which
upgrades
and
what
timelines
like
most
of
like
most
of
the
fips.
C
If
they
pass-
and
you
know
they
get
voted
in
like
we're
going
to
implement
it
eventually,
but
it's
like
if
you
know
if,
if
they're
like
yeah,
we
want
like
20
of
these
fifths
to
be
implemented
in
like
two
months.
It's
like,
I
don't
know
if
that's
like
possible,
so
that's
kind
of
like
I
mean,
obviously
that's
a
very
extreme
example
and
hasn't
happened
yet
and
all
that
but
kind
of
my
point
is
it's
like
I
think
you
know,
our
fips
process
is
good.
A
A
A
Right
like
that
sounds
like
someone
might
be
sprinting
towards
some
internal
improvement.
That
has
nothing
to
do
with
the
network,
but
a
sudden
large
network
upgrade
will
kind
of
toss
all
of
our
plants
aside.
So
things
to
do,
there
is
yeah
for
us
to
generally
stay
in
sync
with
what
to
kind
of
have
a
sense
of
what
the
other
implementations
kind
of
like
goals
and
roadmaps
are,
will
be
good,
but
also
a
lot
of
it
will
potentially
come
down
to.
We
need
to
move
kind
of
slowly.
A
We
need
to
move
roughly
as
slow
as
the
as
yeah.
Whoever
whoever's
needs
the
most
time
for
for
where
an
implementation
might
be
and
yeah,
because
there's
there's
lots
of
differences
here
right,
like
some
implementation,
like
some
some
of
us
share
actors
and
therefore
can
split
the
work
between
us,
whereas
others
are
re-implementing
actors
and
therefore
have
a
bunch
more
work
to
do
so
yeah.
I
think
I
think
the
system
will
slowly
fall
in
place
right.
You
were
gonna,
say.
G
Yeah,
I
was,
I
was
gonna,
try
to
make
progress
on
on
I'm
helping
the
system
fall
in
place,
so
so
yeah,
here's
here's
an
idea
which
I
think
cut
and
trying
to
incorporate
the
ideas
discussed
here.
So
we
could
say
add
three
months
to
the
last,
the
last.
The
major
version
update
so
like
that's
like
june
3rd,
or
something
set
that
as
the
timeline
and
in
the
future
attempt
to
maintain
this
fixed
pace
of
releases.
G
G
Here
is
where
we
discuss
hash
it
out
and
say:
look
like
I'm
we're
not
going
to
be
able
to.
You
know
get
this
done,
or
this
done
like,
let's
cut
back
scope
or
we
all
think
we
can
do
more.
Let's,
like
add
this
to
the
list,
and
we
can
use
the
structure
of,
like
you,
know,
optional
upgrades,
which
I
have
here
to
allow
people
to
kind
of
get
ahead
without
holding
up
the
upgrade
and
then
maybe
like
so
so
further
proposal.
G
If
so,
so
we
make,
we
make
a
commitment
at
some
point.
I
in
this
case
we're
a
little
bit
behind.
So
maybe
it's
a
little
bit
weird,
but
in
the
future
like
say,
like
you
know
the
week
after
the
previous
upgrade
or
maybe
two
weeks
or
something
we
make
a
commitment
to
okay,
this
is
like
the
set
of
features
that
we
agree,
we'll
have
and
then
yeah.
I
guess.
G
The
thing
that
I'm
not
so
sure
about
is
is
how
we
handle
it
when
say
like
one
implementation
slips,
so
that,
like
the
two
options,
are
we
push
the?
I
guess
the
three
options?
Are
we
push
the
upgrade
date
which
doesn't
sound
great?
If
we're
trying
to
do
this
fixed
cadence,
the
other
option
is
we
cut
that
feature
out
and
then
the
third
option
is
we
let
that
implementation
slide
off
of
mainnet,
which
also
you
know
seems
not
so
great?
G
C
Yeah
I
that
that
was
kind
of
what
I
was
going
to
suggest
and
maybe
to
even
be
more
sure
about.
You
know,
like
your
concern
about
you,
know,
implementations
like
slipping.
It's
like,
I
think,
it's
very
useful
to
commit
to
a
vague
kind
of
time
frame.
So
from
what
I've
seen
like
in
other
blockchains,
I
mean
like
I
guess.
C
Ethereum
is
probably
probably
what
I'm
thinking
of
usually,
but
it's
like
you
know,
they
have
like
kind
of
scheduled
like
cadence
of
hard
forks
it
feels
like,
and
then
it
doesn't
really
feel
like
they
set
like
a
date.
Until
you
know
all
the
implementations
have
implemented
it,
and-
and
you
know,
when
they
start
setting
the
date,
then
you
know
that's
when
they
do
a
bunch
of
the
testing
and
all
that
stuff.
So
I
don't
think
we
should
even
be
committing
to
a
specific
date
and
just
giving
a
vague.
C
G
A
Yes,
ish
is
my
opinion.
I
I
kind
of
feel
like
like.
Oh
a
one
size
fits
all
approach,
won't
work
here,
like
it's
very
much
going
to
be
a
case
by
case
thing
where
yeah.
So
I
broadly
agree
with,
like
the
idea
of
we'll
say
that
you
know
the
upgrade
happens
in
june,
using
this
one
as
an
example-
and
you
know
it
can
be
june
september
january
and
so
on.
I
think
I
think
that
makes
sense
and
the
scope
kind
of
yeah
is
fleshed
out
in
a
place
like
this.
A
I
think
when
it
comes
down
to
the
choosing
between
those
three
options
of
like
disco,
push
the
release
or
let
let
an
implementation
slide
out.
I
think
that'll
probably
have
to
come
to
a
case-by-case
basis
where
sometimes
pushing
the
release
might
make
more
sense,
and
sometimes
these
scoping
might
make
more
sense.
I
think
I
think
letting
a
letting
an
implementation
flight
off
of
mainnet
should
always
be
the
last
option.
Slash
shouldn't
be
on
the
table,
but
yeah.
A
Because,
like
pushing
a
timeline,
isn't
the
worst
thing
in
the
world,
but
nor
is
cutting
scope,
if
especially
for
say:
okay,
it's
getting
cut
out
of
this,
but
that
means
it'll
be
in
the
network
two
months
from
now,
because
that's
when
the
next
drop,
it
is
seems
fine
to
me,
but
again
it'll
depend
on
what's
actually
being
cut
from
scope
or
what
the
timeline
slipping
by
is.
Is
that
one
week,
or
is
that
two
months,
that
kind
of
thing?
It's
just
my
guess.
C
Yeah
I
mean,
like
I
said
I
generally
don't
see
like
time
when
I'm
still
slipping
by
many
months,
especially
if
it's
like
actors
upgrade
things,
because
those
are
quite
isolated
changes,
but
yeah
I
mean
I,
I
totally
totally
get
what
you're
saying
as
well,
but
yeah,
I
don't
know,
maybe
I'm
being
overly
optimistic,
but
I
don't
realistically
see
timelines
slipping
by
a
few
months,
at
least
on
the
implementation
level
for
actors.
I'm
not
sure,
though,.
A
The
miner
to
you
know,
start
aggregating
proofs
and
you
know
actually
use
the
change,
but
that's
not
what's
needed
for
the
network
upgrade
itself
like
if
we,
if
we
wanted,
we
could,
like
other
implementations,
could
potentially
just
get
the
consensus
parts
of
it.
So
they
can
like
stay
in
sync
with
the
network,
and
then
you
know
any
miners.
Their
miners
won't
actually
start
aggregating
proofs
until
that
happens
in
some
smaller
release
down
the
road,
and
I
wonder
if
that
potentially
be
a
pattern
with
with
big
changes,
quote-unquote,
that
land.
A
Using
the
optimistic
window
posting
as
an
example-
and
this
doesn't
really
the
analogy
doesn't
hold
up
as
well,
but,
like
writing
the
disputer
to
actually
dispute
these
posts,
is
the
smaller
non-consensus
critical
piece
that
you
know,
implementations
can
do
in
their
own
time
or
choose
to
not
do
it
all,
and
then
the
the
consensus
part
of
it
is
is
a
smaller
kernel
of
change
that
is
easier
to
digest.
So
maybe
we'll
wind
up
in
that
place.
I
I
think
there's
a
lot
of
like
learning.
A
E
Yeah,
I
agree
actually
for
all
this
discussion
and
yeah.
Personally,
I
would
like
to
have
a
easier
plan
for
a
release
and
based
on
that,
we
yeah
we
yeah,
and
I
would
think
we
could
review
that.
You
know,
for
example,
in
this
meeting
and
to
have
you
know
the
plan
to
yeah
to
adjust
the
plan
actually
yeah.
For
example,
if
we
have
some
difficulties
to
meet
this
schedule
yeah,
but
we
will
try
to
beat
the
schedule
right
and
yeah
if
we
cannot
yeah,
we
could.
A
Yeah
strong
agree,
I
think
I
think
the
community
having
finally
having
a
sense
of
you,
know
a
kind
of
longer
term.
Five
point
roadmap
will
be
great.
I
mean
like
this.
These
are
when
the
upgrades
are
planned,
and
this
is
what
is
probably
going
to
happen
in
them.
I
think
that's
something
that
we're
not
providing
right
now,
which
would
be
it
would
be
good.
A
G
Yeah,
I
have
a,
I
guess,
a
closing
thought,
thanks
for
all
the
discussion
and
if
yeah,
if
the
actors
v4
plan,
seems
like
it's,
it's
good
enough
to
get
started
on
the
the
proposed
way
forward.
As
I
see
it,
yeah
just
please
comment
in
the
issue
as
other
implementers.
If
this,
if
the
the
necessary
set
of
changes
proposed
for
v4,
seems
achievable
by
june,
so
we
can
try
to
yeah
get
going
on
having
a
concrete
feature
set
for
you
know,
rough
june
that
we
can.