►
From YouTube: Filecoin Core Devs Biweekly #3
Description
Recording for: https://github.com/filecoin-project/tpm/issues/5
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
A
Omar
and
austin
are
on
the
chain
safe
team,
along
with
eric,
and
I
think
raslan
is
here
to
help
represent
the
surmitsu
team,
because
I
think
maxim
wasn't
able
to
make
it
today
russell-
and
I
don't
know
if
there's
other
folks
on
your
team,
that
you'd
want
to
highlight-
and
we
have
a
number
of
folks
from
either
the
cross,
implementations,
design
teams
and
the
lotus
team.
B
Okay,
thank
you
morty.
This
is
this
is
steven
and
I'm
from
the
ipa
force
community
and
I'm
located
in
shanghai
and
as
a
and
I
think,
one
of
the
major
and
ipf's
and
falcon
and
communities
and
yeah
in
china
and
also
in
asia.
We
have
some
yeah,
we
we
we
had
hold
yeah
some
meetups
and
and
actually
we
have
a
weekly
meetups
to
either
and
all
the
ips
or
falcon.
B
Who
are
very
interested
in
this
technology
and
about
decentralized
digitalized
storage
industry,
and
we
we
and
actually
we
have
more
than
140
meetups.
We
call
it
opend
ipvs
episodes
open
day
yeah,
which
is
running
very
well,
and
we
also
you
know,
focusing
on
the
yeah
falcon
mining.
B
Yes,
since
last
year
the
falcon
open
source
yeah
and
once
we
participated,
the
all
the
yeah
tablets
test
days
basis
and
yeah.
You
could
say
overload
in
the
this
this
this
and
the
ipv
is
for
snow,
yeah
and
we're
very
happy
to
and
to
join
this
and
to
work
on
the
gill
falcon.
We
will.
B
We
would
like
to
develop
the
guilfoc
implementation
and
as
a
different
one
than
notice,
to
provide
functions
for
yeah,
especially
for
the
managing
services,
for
example,
as
a
disability,
mining
pool-
and
there
are
some
functions
into
us.
We
would
like
to
decouple
some
functions
and
to
have
many
kind
of
components,
and
just
something
like
this:
okay
yeah,
I
will
update
the
google
file
condition
yeah.
Thank
you.
A
Awesome
we're
super
excited
to
have
you
and
awesome
that
you
guys
are
bringing
an
additional
perspective
to
how
we
can
make
our
various
stylecoin
implementations
super
strong
and
differentiated
and
offer
lots
of
benefits
to
different
users,
so
very
happy
to
have
you
and
thanks
for
being
so
flexible
on
timing.
It's
a
terrible
time
in
china,
but
we
really
appreciate
it.
C
A
Awesome
cool
the
next
thing
on
our
identity
today
was
to
talk
more
about
spec
actors.
V2
we
have
both
wyatt
and
steven.
A
Wyatt
was
one
of
the
main
implementers
on
the
the
whole
v2
upgrade
inside
of
the
spec
actors
and
steven
did
a
lot
of
the
integration
work
into
lotus,
and
so
they
can
kind
of
both
speak
to
the
different
components
of
making
the
spec
actors
v2
and
the
0.9
release
that
that
encompasses
and
upgrades
to
it
happen
and
kind
of
what
was
involved
from
a
technical
aspect
and
then
maybe
answer
questions.
A
D
Yeah
thanks
molly
yeah,
so
I'm
going
to
go
pretty
quick,
there's
like
a
decent
amount
to
cover
I'll,
just
go
after,
like
by
actor
and
just
touch
things
like
a
really
high
level
before
we
dive
in
more
so
by
far,
the
biggest
changes
were
in
the
minor
actor
I'm
going
to
go
through
some
of
those
yeah,
so
we
did
some
balance
refactoring
based
on
some
good
feedback
during
an
audit
to
make
things
clearer
and
less
likely
to
break
so
we
we
track
debt.
D
We
track
all
the
fees
that
we
incur
in
a
field
called
fee
debt
which
persists
debts
which
need
to
be
paid
back
across
other
calls.
We
also
now
keep
the
initial
pledge,
always
on
the
minor
actor
instead
of
having
the
idea
of
ip
debt,
which
simplifies
a
lot
of
things.
D
Okay,
then,
there's
also
the
matter
of
consensus
faults.
There
were
some
issues
where
they
could
be
replayed,
which
was
not
good
and
they're.
Also,
I
guess
even
even
more
so
there
were.
There
were
big
scalability
issues
with
terminating
the
entire
minor
during
a
consensus
fault,
so
things
are
much
less
drastic
in
the
case
of
the
minor
consensus
faults.
There's
a
lockout
through
the
node
integration
from
the
election
for
a
period
of
finality
blocks
and
there's
also
a
fee.
D
That's
incurred,
okay,
there's
something
stephen
can
talk
about
since
he
implemented
this
delayed
sector
power,
so
a
sector
doesn't
get
power
now
on
proof
commit
it
gets
power
on
the
first
submit
post.
I
believe
and
there's
some
like
state
added
to
the
partition
and
I
think
maybe
the
deadline
strucks,
maybe
just
the
partition,
which
help
us
keep
track
of
that,
and
do
that
correctly.
D
There
are
back
to
fees.
There
were
some
changes
in
the
pre-commit
deposit
fee,
just
bringing
it
down
and
also
some
some
of
the
more
complicated
changes
in
the
termination
fee
in
order
to
handle
some
edge
cases
around
cc
upgrades
so
that
we
could
close
a
loophole
where,
if
you
ccc
upgraded,
you
could
end
up
paying
a
lower
termination
fee
based
on
variation
and
some
of
the
underlying
some
of
the
yeah,
the
the
reward
and
the
and
the
total
power.
In
the
network,
so
we
can
dive
into
that
more
too.
D
I
keeping
on
the
the
fees
track.
There
was
a
pretty
significant
change
in
terms
of,
in
terms
of
I
guess,
making
filecoin
less
aggressive
with
faults,
so
the
three
big
high-level
things
here,
there's
no
longer
a
fee
charged
on
recovery,
there's
no
fee
for
your
first
miss
post
and
in
order
to
compensate
for
making
these
things
more
forgiving,
there's
also
a
higher
we
bumped
up
the
fault
fee.
A
bit.
D
I
took
3.5
expected
days
of
block
reward,
okay,
I'll
keep
keeping
like
halfway
through
the
minor
at
this
point
so
set
your
commitments.
They
reject
duplicate,
deal
ids,
we've
teased
out
some
of
the
the
parameters,
so
the
seal
challenge
looked
back
and
the
proof
commit
delay,
parameter,
have
been
separated
properly
and
some
of
their
values
have
been
tweaked,
but
the
two
control
address
yeah
two
yeah
two
big
control
address
changes,
so
the
worker
address
no
longer
uses
cron
in
order
to
process
changes
to
the
worker.
D
Address,
there's
like
a
two
stage,
two
message
invocation
process:
to
do
that.
We
also
introduced
a
change
worker
address
method,
which
also
has
some
sort
of
two-stage
process
along
like
through
a
single
method.
D
There
was
a
pretty
sizable
bug
caught
during
an
audit
but
too
late
for
space
race
which
actually
affected
some
things,
but
we've
got,
and
so
I
guess
we
call
that
the
cc
upgrade
and
then
fault
bug
we
can.
We
can
dive
more
into
that,
but
basically
we
weren't
accounting
for
the
fact
that
when
you
move
sectors
out
of
an
expiration
queue
during
the
cc
upgrade-
and
we
weren't
accounting
for
this
possibility
during
fault
handling,
and
so
we
ended
up
with
some
corrupted
state.
So
that's
fixed.
D
Now,
that's
that's
one
of
the
bigger
changes
in
the
internal
logic
like
partitions
and
expiration,
cues
yeah.
So
that's
something
we
can
get
into
there's
a
change
to
the
proving
period.
We
owe
it
now
during
minor
creation.
We
always
start
the
proving
period
in
the
past,
instead
of
potentially
in
the
future
yeah.
There
are
a
few
other
errors,
smaller
things
which
have
been
corrected,
but
that
wraps
up
the
that
wraps
up
the
minor
actor
at
a
high
level
and
then
whipping
through
the
rest.
D
So
there's
been
a
change
to
the
baseline
function
in
the
reward,
actor
and
there's
also
been,
which
zx
is
here,
and
you
can
you
can
help
us
with
some
of
the
implications
of
the
details
behind
that
too.
It's
also
been
a
very
recent
change
to
multiply
the
minor
penalty
by
3x
in
the
case
that
yeah,
in
the
case
of
the
like,
the
minor,
for
example,
doesn't
have
enough.
I
guess
includes
messages
which
which
can't
pay
gas
right.
D
D
This
new
change,
where,
when
they
resolve
id
addresses
which
don't
when
they
yeah
when
they
try
to
resolve
an
account
address
which
does
not
yet
have
an
id
address
instead
of
failing,
they
actually
go
through
and
create
the
mapping
into
that
in
the
init
actor
and
and
do
things
that
way
and
they
all
use
the
same.
The
same
code
path
for
that.
So
that's
all
kind
of
grouped
together
and
then
yeah
the
multi-sig.
There
are
a
few
bugs
a
few.
A
few
clarifications
so
like
there
was
a
truncating
division
bug.
D
There
was,
let's
see
yeah
we
we
allow
investing
start
to
be
set
at
the
yeah,
the
investing
start,
epic
to
be
said
at
construction
and
there's.
Also
a
nice
nice
cleanup
where
we
purge
the
approvals
from
the
pending
transactions
list,
append
transactions
queue
when
we
swap
or
remove
a
signer
and
then
last
thing
I'll
mention.
D
You
know
it
goes
across
the
actors,
because
we
all
use
the
hamps
and
all
the
different
actors,
and
there
was
there
was
a
internal
bug
where
internal
node
ordering
of
the
hamps
violated
the
variant
which
would
cause
non-deterministic
ordering,
depending
on
yeah
yeah
yeah.
Depending
on
when
you
insert
and
deleted
things
yeah,
so
that's
that's
it.
It's
a
lot
happy
to
dive
in
more
also
take
any
comments
from
stevens
ex.
A
Do
you
wanna
also,
maybe
give
like
a
very
high
level
description
into
how
the
spec
actors
v2
is
architected
or
designed
around
like
being
able
to
have
different
versions
at
different
heights?.
D
Yeah,
I'd
love
to
so
one.
Yes,
a
lot
of
work
we
did
was
to
just
extract
out
a
lot
of
shared
types
in
order
to
keep
things
a
bit
simpler,
so
that
was
a
whole
set
of
work.
A
lot
of
the
abi
has
moved
from
specs
actors
to
this
go
shared
types
or
go
state
types,
repo
yeah,
so
so
yeah
with
that,
I
guess
the
the
biggest
yeah
yeah
yeah,
the
the
highest
level.
D
Most
important
thing
is
that
we're
using
different
version
go
we're
using
go
module,
major
versions
in
order
to
keep
track
of
yeah
of
these
major
version,
spectacular
changes,
so
things
which
yes,
anytime,
there's
like
a
state
breaking
change,
we're
using
a
different
go
module.
So
right
now
we
have
v0,
which
is
the
thing
that
was
running
on
space
race
and
we
have
v2
which
we're
going
to
try
to
upgrade
in
this
weekend
yeah.
So
that's
yeah!
That's
that's
like
the
most
important
thing
to
keep
in
mind.
D
We're
also
yeah
the
way
we're
approaching
like
smaller
changes,
which
don't
require,
which
don't
require
like
a
a
large
redesign
or
don't
require
a
like.
A
state
change
like
a
change
for
the
schema
of
the
actor's
state
is
where
we're
consuming
a
we're,
consuming
a
version
from
the
run
time
and
then
using.
D
If
statements
to
check
like
okay
is
this
like
version
breeze,
then
we
we
like
can
maybe
compute
a
fee
differently,
for
example,
so
yeah
just
so
that
that's
like
kind
of
a
quick
and
dirty
thing
for
simpler
changes
between
the
bigger
upgrades
and
then
the
the
bigger
upgrades.
We're
keeping
them
on
in
different
go
modules
which,
like
during
development,
amounts
to
keeping
them
on
on
different
major
version
branches.
So
like
specs
actors
and
then
spectacular,
v2
yeah
is
that
is
that
good,
any
more
any
more
on
that.
A
E
E
I
opened
up
that
issue
about
the
the
problem
that
we
kind
of
ran
into
about
division
of
how
go
kind
of
uses,
euclidean
division
for
big
end
and
then
truncating
for
for
regular,
integers
and
kind
of
wondering
what
what
what
the
truncating
bug
that
you
found
was
relating
to.
D
E
Know
so
yeah,
I
I
put
it
in
the
like
the
specs,
not
the
specs
actors,
just
because
I
assume
this
was
something
that
is
like
not
going
to
change
within
spec
actors,
so
I
just
wanted
to
be
kind
of
documented
on
the
specs
just
because
that
behavior
was
kind
of
undefined
and
wasn't
I
wasn't
like
certain
about
it.
I
can
find
that
issue
number
and
kind
of
link
it.
Okay,.
B
E
E
But
the
link
I'm
talking
about
in
chat
thanks.
A
E
And
I
just
have
one
other
question,
just
kind
of
more
out
of
curiosity
about
the
the
change
that
you
said
was
being
made
where,
when
addresses
are
trying
to
be
resolved,
that
they
don't
exist,
they'll
be
created
right.
That
logic
existed,
I
guess
within
the
multisig
actor.
Is
there
a
reason
that
wasn't
kind
of
expanded
to
these
other
ones
that
you're
adding
it
to
before?
D
A
good
question:
yeah,
yeah,
okay,
so
I've
been
a
little
out
of
touch
with
this
change.
As
far
as
I
understood
it,
they
were
all
added.
At
the
same
time,
it
could
be
that
there
was
a
mistake
in
in
like
saying
that
we
put
this
in
only
in
v2.
Maybe
this
was
already
in
v0,
but
yeah
yeah,
not
nothing!
I'm
aware
of.
I
think
it
was
like
it
was
just
a
good
idea
to
to
do
it
everywhere.
So
I
can.
D
E
A
Yeah,
I
think
there
were
a
couple
of
things
that
that
wyatt
mentioned
that
were
like
things
that
we'd
planned
to
do
only
in
the
spec
actors
upgrade
and
then
might
have
pulled
forward
into
other
releases
if
they
didn't
require
significant
spec
factors.
Upgradability
functionality.
One
of
the
reasons
this
one
is
so
large
is
that
it's
making
use
of
of
all
of
the
the
new
upgradability
logic
within
spec
actors
to
allow
us
to
do
some
larger
actors,
side
changes.
G
Well,
one
thing
that
makes
the
actress
v2
special
is
that
it
changes
the
actual
on
disk
state.
So
all
the
previous
upgrades
would
just
like
tweak
values
or,
like
maybe
like
modify
state
between
logic,
whether.
E
E
So
I
guess
just
like
on
that
topic,
just
to
kind
of
just
a
quick
point
on
that
since,
since
the
like,
all
these
other
changes
that
don't
affect
the
state
can
be
made
more
easily,
then
for
cases
like
the
amped
and
the
hammed
could
their
cash
may
not
be
updated
without
that
breaking
you
know
huge
version
bump.
Just
to
like
reduce
gas
fees,
I
mean
there's
a
ton
of.
G
Yeah,
so
the
the
bug
in
the
amt
cannot
be
fixed
without
rewriting
state.
Unfortunately,
the
in
terms
of
caching,
yes,
that
can
be
done
in
a
simpler
network
upgrade
it
won't
require
a
full.
Well
it'll
still
be
a
bit
tricky
because
we
need
to
make
sure
the
old
version
before
the
new
version
after,
but
yes,
we
should
be
able
to
do
that
without
like
doing
this
massive
state
abstraction
thing
yeah
and
that
that
is
planned,
because
the
behavior
is
so
optimal.
E
A
Maybe
we
let
stephen
tell
us
a
little
bit
about
the
any,
especially
if
there's
any
parallel
complexity
that
when
other
teams
are
considering,
you
know,
from
a
from
a
design
perspective,
how
to
build
themselves
from
the
get-go.
To
make
this
a
little
bit
easier.
A
We
found
we
needed
to
do
a
lot
of
refactoring
once
we
realized
that
we
needed
this,
but
if
there
is
any
lessons
learned
that
we
can
pass
on
to
other
teams,
especially
anything
that
will
be
useful
across
languages,
because
we
do
have
you
know
c,
plus
plus
rust,
other
groups
that
might
not
have
to
go
through
the
same
rare
remote.
We
did
with
go
that'd,
be
super
useful.
G
Yeah,
so
I
found
that
in
lotus
at
least,
we
had
two
well
they're,
really
three
main
components:
one
is
the
migration
component,
where
you
actually
call
the
upgrade
at
a
specific
height
the
way
lotus
does
it
says
like
basically
right
after
the
height
right
before
the
next
block,
it
will
call
the
grade
method
there.
G
The
migration
method,
which
will
then
do
whatever
internal
state
migrations,
need
to
happen
in
retrospect,
it'd
be
kind
of
nice
to
make
this
a
little
more
incremental,
so
we
could
do
like
pre-migration,
so
we
can
make
this
faster
at
the
moment
it
can
take
up
several
minutes
for
the
like
the
v2
upgrade,
because
we're
writing
all
of
state
is
not
that
fast.
The
other
two
components
are
state
abstractions
and
message
abstractions.
So
because
we're
changing
the
internal
state
representation,
we
have
to
abstract
over
the
state.
G
The
way
we
did
this
in
lotus
now
is
we
have
these,
like,
basically,
just
trade
objects
or
interface
objects,
whatever
language
you're
coming
from
just
optics
abstract
over
like
the
concept
of
a
minor
actor
and
allow
you
to
form
queries
on
this
minor
actor.
This
allows
the
future
to
potentially
break
object
into
multiple
pieces
or
like
mush
them
back
together,
without
having
to
actually
like
change
the
logic
that
interacts
with
these
objects.
G
At
the
moment,
we
don't
currently
have
much
support
for
modifying
actors
to
use
interfaces
in
the
future.
We've
been
added
some,
but
most
of
the
modifications
to
these
objects
will
come
through
nearly
all
will
come
through
the
actor's
vm
itself
or
the
spectaculars
themselves,
because
that's
the
entire
point
of
blockchain
most
of
the
time,
lotus
itself
is
not
going
to
be
modifying
them.
So
that's
fine.
The
final
piece
is
the
abstraction
of
messages
we
haven't
done.
G
Actually
we
haven't
actually
put
much
work
into
this
in
lotus,
because
the
like
this
upgrade
doesn't
touch
too
many
messages.
It
only
changes
a
couple
of
them,
I'm
not
happy
with
current
abstraction
we
have,
but
I
don't
know
what
the
right
abstraction
here
is.
The
current
abstraction
basically
lets
you
say
like:
I
need
a
message
for
this
version
of
an
actor.
So
basically
you
you,
it's
eventually
just
a
builder
api,
so
it's
a
build
message
for
a
version
of
actor
that
does
some
operation.
Unfortunately,
this
won't
work.
G
If
we
change
like
semantics
around
how
message
messages
operate,
it
also
won't
work
if
we
change
semantics
around
the
cab
proof
should
operate.
This
is
an
unsolved
question.
We
haven't
figured
out
yet
in
terms
of
upgrade
pads.
Basically,
everyone
has
two
options.
You
can
either
implement
like.
G
Basically,
you
can
implement
the
system
where,
like
you,
can
run
the
old
version
of
the
world
and
then
atomically
switch
the
new
version
of
the
world
at
runtime,
or
you
can
choose
not
that
the
the
not
implementing
that
path
is
basically
before
the
upgrade.
You
tell
everyone.
Okay,
switch
to
a
miner
that
supports
this
temporarily
for
the
upgrade
like
run
with
that
with
another
minor
software.
G
For
a
bit
of
time,
then,
like
on
the
side,
you
implement
the
like
the
upgraded
logic
in
your
file
implementation
and
then
once
basically
like
once
falcon
no
longer
needs
to
look
back
at
previous
versions.
Then
you
can
say:
okay
switch
back
to
like
this
alternative
focal
implementation.
G
G
Obviously,
the
ideal
solution
is
didn't.
Look
like
the
full
system
where
you
do
the
upgrades,
but
this
can
be
tricky
because
you
have
to
maintain
both
versions
at
the
same
time,
I'm
not
sure
what
lotus
will
do
here.
I
assume
that
eventually
we
may
drop
support
for
conversions
once
we
have
checkpoints.
G
A
Yeah,
I
think
the
the
second
solution
that
stephen
was
pointing
out
there
of,
like
you
know,
since,
since
none
of
the
other
implementations
yet
have
this
full
upgradability
logic,
syncing
from
a
snapshot
or
switching
over
once
to
one
of
those
implementations.
You
know,
after
this
sort
of
a
spec
actors
upgrade.
We
do
not
expect
to
use
this
functionality
frequently,
but
I
think
it's
really
important
that
we
have
the
capability.
If
we
need
it,
then
we
can
start
thinking
from
there
and.
G
We'll
get
like
there
are
two
kinds
of
upgrades
like
there
are:
the
like:
okay,
we're
going
to
go
and
tweak
some
state,
because
there's
some
bug
and
between
some
logic
this
is
something
that's
fairly
easy.
Just
manual
implementations
for,
like
you
have
your
active
quotation.
It
says
if
I
am
network
version,
whatever
do
this
reverse,
and
this
do
this
and
they're
interested
helping
switches
over
this
is.
G
The
special
part
about
actors,
v2
upgrade,
is
that
we're
literally
like
rewriting
all
the
state
and
trying
to
accept
two
copies
of
the
state.
The
other
special
part
is
that
we're
actually
changing
the
message
formats,
at
least
in
one
or
two
cases.
This
isn't
going
to
cause
any
like
launching
problems,
because
the
messages
can't
be
confused
and
they're
also
like
we're
not
changing
like
the
the
minor
proof
message
or
anything
like
that.
It's
a
couple
things
for
application
channels
and
stuff
like
that
that
shouldn't
matter,
but
it
does
make
upgrading
a
bit.
C
Tricky
while
you're,
muted.
A
I
love
how
it
gives
you
the
message
now,
it's
useful
any
any
other
questions
based
on
the
kind
of
lotus
side
of
implementing
the
spectractors
upgradability
logic.
D
I
have
just
a
quick
reply
to
austin
I
just
I
looked
through
and
you're
right.
The
the
whole
id
address
resolution
commit,
I
believe
that
was
on
you
know
that
seems
to
have
been
on
v0.9
and
I
think
yeah.
It
also
was
added
into
verified
registry
and
and
payment
channel
at
the
same
time,
yeah
thanks
for
calling
that
out.
D
Sorry
yeah
sorry,
this
is
this
is
just
specs
actors
v09,
so
that
just
means
this
has
been
on
space
race
yeah.
So
this
is
not.
D
V2,
this
is
v0
actors
already
had
that.
D
C
Don't
think
that's
the
case,
but
maybe
maybe
you
should
clarify
offline.
E
Yeah,
I
can
look
into
this
later,
because
I,
if,
if
there
is
a
difference,
I
need
to
make
a
change
on
on
our
version,
at
least
for
now,.
A
This
is
probably
the
the
largest
most
exciting
state
upgrade
that
we
have
done
yet
so
continuing
to
stress
test
and
improve
things
before
we
get
to
maine
at
launch,
which
is
good,
gives
us
a
lot
more
confidence
that
we'll
be
able
to
have
all
the
tools
in
our
toolbox
once
we
get
to
a
live
open
network
to
respond
to
whatever
comes
our
way
but
yeah
interested.
If
there's
any
other
questions
from
folks.
C
Here,
one
thing
that
I
want
to
share
is
one
piece
of
information
that
we
haven't
provided
y'all.
As
far
as
I
know,
it's
a
list
of
the
various
four
key
things
that
live
on
the
current
ignition
network,
so
the
various
upgrade
epochs
and
the
things
that
change
I'm.
If,
if
obviously
y'all
could
discover
this
from
the
code
itself,
that's
probably
not
gonna
be
super
fun.
So
if
syncing
the
network
from
ignition
genesis
up
to
wherever
is
a
goal
of
yours,
I'm
guessing.
C
I
will
probably
need
some
concise
description
of
what
changes.
The
variety
box,
because
some
of
the
places
are
honestly
fair,
a
little
messy
because
just
because
we
fix
bugs
along
the
way
in
in
consensus,
breaking
releases
so
molly.
If
we
can
maybe
track
that
as
a
deliverable,
that
we
have
to
provide
that'd,
be
good
because
it'll
be
a
nightmare
for
y'all.
Otherwise,.
A
A
Awesome
going
back
to
our
agenda
the
next
thing,
I'd
added
actually
before
status
updates
was
fifth
prs.
I
think
zx
was
calling
out
there's
a
couple
of
open
prs
to
the
fip
process,
which,
if
we
had.
A
Chrome
windows:
you
know
what
I'm
just
gonna
send
this
to
you.
Instead
of
sharing
a
random
chrome
window
that
I
can't
see
cool
so
right
now,
I
believe
we
have
two
open
fit
pr's,
one
updating
the
fip
template,
which
is
the
the
one
opened
by
zx
just
about
two
weeks
ago,
actually
about
re,
I
think
renaming
a
couple
of
sections
and
then
adding
two
new
pieces
to
to
the
flip
template
for
new
falcon
improvement
proposals.
F
Yeah,
so
for
the
renaming
I
think,
like
there
are
like
a
few
repetitive
like
headers,
and
sometimes
it
gets
a
bit
confusing
what
they
really
mean
so
like
just
making
making
the
intent
clearer
like,
for
example,
the
motivation
is
about
the
problem.
Some
people
can
say
it's
redundant
and
then
the
rationale
is
about
the
design
ratio.
F
Now,
because
you
could
get
confused
with
like
motivation
of
and
and
so
on,
so
like,
I
think
having
that
makes
it
clearer
and
then
I
think
another
two
important
considerations
for
fib
is
one
is
about
incentive
and
the
other
one
is
about
product,
because
in
ethereum
then
there's
only
security
consideration
as
a
must,
but
I
think
like
given
that
this
is
like
pretty
complex
storage
economy,
and
then
we
are
here
to
provide
like
reliable
and
useful
storage
and
makes
right
product
more
attractive.
F
I
think
that
all
fib
should
at
least
give
thought
or
demonstrate,
like
some
kind
of
consideration
in
these
two
access,
and
sometimes
like
trade-offs,
needs
to
be
made
as
well.
It's
good
to
have
them
inside
the.
A
Makes
sense
to
me
yeah
generally
like
designing
a
fit.
You
know
it's
a
complex
system,
thinking
about
how
your
your
fifth
is
going
to
change
the
the
underlying
you
know,
for
example,
fips
are
like
great:
let's
get
rid
of
all
fees
ever
like
well,
your
incentive
incentive
considerations
on
that
fit
must
be
very
impressive.
To
think
about
how
that's
not
going
to
you
know,
break
from
either
security
or
an
incentive
alignment
perspective.
So.
A
I
think
I
think
the
other
pr
is
not
quite
ready
for
for
feedback,
yet
I
don't
think
it
has
most
of
the
sections
filled
out,
but
I
think
the
stephen
this
might
be
interesting
to
you,
because
I
think
they
are
asking
for
pools
for
small
miners,
and
so
here
you
go.
Here's
a
an
early
grafted,
a
fit.
That's
demonstrating
some
demand
for
folks
to
add
that
sort
of
functionality.
A
So
I
don't
think
it's
an
actual
full
sip
yet,
but
it
demonstrates
some.
A
Interest
awesome
cool
now
we're
to
the
agenda
item
around
status
updates
so
generally,
what
we
do
here
is
just
go
around
across
each
implementation
and
give
a
quick
update
on
where
things
where
your
teams
are
at
anything
that
we're
you've
achieved
or
have
been
working
on
over
the
past
two
weeks
and
then
kind
of
you
know
some
top-level
milestones
that
you're
hoping
to
hit
for
the
next
couple
of
weeks.
Until
we
get
to
meet
again,
it
would
be
useful.
A
Maybe
let's
see
we,
we
made
chains
of
go
first
last
time,
maybe
wristland.
Do
you
want
to
give
us
an
update
on
the
saramitsu
side.
H
H
Yeah,
that's
fine,
so
we've
recently
been
focusing
on
delivering
two
parts.
Basically
of
of
our
job.
First
one
is
the
node.
The
second
one
is
miner
storage
miner.
H
So,
as
for
the
storage
miner,
we
have
made
it
work
with
version
zero,
five
four
of
lotus
and
our
our
own
node
is
still
on
zero.
Five
four
compatible
version
of
auto,
so
our
goal
was
to
make
both
parts
work
and
then
bump
our
versions
of
both
monitor
and
node
up
to
which
will
be
actual
at
the
moment.
H
So
we
just
had
a
talk
with
molly
yesterday
and
seems
like
the
reasonable
version
for
now
is
0.90.
H
E
H
H
We'll
have
to
assess
what
exactly
have
to
be
changed
in
order
to
be
compatible
with
the
latest
versions
of
lotus,
and
there
are,
there
were
quite
a
few
of
them
after
zero
five
four,
so
we
are
currently
on
the
process
of
assessing
what
exactly
have
to
be
changed
after
that
we'll
prepare
change
list
and
go
through
it
implementing
one
by
one
yeah
and
we
have
integrated
test
vectors.
But
this
is
what
this
was
in,
which
this
was
in
an
initial
version
of
test
vectors
provided
together
with
054.
H
So
this
was
the
first
bunch
of
vector
test
factors
they
have
passed
successfully.
This
was
well,
it
was
really
easy,
because
we
previously
we
had
more
or
less
compatible
version
of
node.
It
was
just
to
verify
that
it
produces
the
same
result
as
we
expect
to
so
what
we're
going
to
do
partially
to
analyze.
H
What
exactly
is
not
working
is
we're
going
to
take
all
the
test
factors
that
are
possible
that
are
available
for
us
right
now
and
try
to
test
against
them
and
see
what
the
differences
and
basically
use
them
as
you
intended
them
to
be
to
analyze.
What
what
are
the
incapabilities
and
see
what
what
should
be
changed?
H
So
this
is
our
plan
for
the
next
two
weeks
and
hopefully
well
for
many,
it
seems
to
be
that
it
can
be
relatively
easy
to
the
node
itself.
As
for
the
node,
we
will
see.
A
I
I
was
just
typing
them
yeah,
so
since
you're
getting
started
with
this,
there
are
two
things
that
I
think
you
you
should
be
aware
of.
Where
jumping
might
help
your
debugging
process
as
you
find
differences,
one
of
them
is
that
all
test
vectors
have
embedded
execution
traces
in
them.
They
are
saved
in
base64.
They
are
deflate.
They
are
deflated
in
g7
and
saved
in
v64,
so
you
should
be
able
to
rip
them
out
very
easily
and
kind
of
like
compare
side
by
side.
I
If
something
has
gone
wrong
and
then
another
thing
that's
useful,
is
we
built
a
tool?
That's
called
state
div,
which
allows
you
to
compare
two
state
trees.
It
doesn't
matter
what
implementations
they're
coming
from
as
long
as
you
can
output
the
state
tree
into
a
car
file,
it's
good
enough.
This
tool
will
be
able
to
process
it,
so
it's
kind
of
like
a
it
prints,
a
very
helpful
diff,
compar
diff,
like
output,
that
compares
two
state
trees.
I
We
use
this
automatically
when
we,
when
we
find
a
vector,
so
our
ci
jobs
use
this
when
they
find
a
mismatch
to
kind
of
like
give
give
us
a
bit
of
information
of
what
avoid
might
be
wrong,
but
we
built
this
as
a
tool
that
is
a
cli
tool
that
can
be
used
by
any
implementation.
So
I
think
this
this
would
be
useful.
We
use
this
by
the
way
yeah
we
use
this,
but
with
with
a
three-way
diff.
I
H
F
A
I
If
you
need
any
pointers,
just
shout
out
to
us
in
the
in
the
field
test,
vectors
channel
and
we'll
jump
on
it.
C
C
C
Oh,
no,
I
know
is
essentially
our
consensus,
frozen
version
for
actual
mainnet
for
the
liftoff
epoch,
which
is
on
wednesday,
so
we'll
probably
have
some
more
releases
go
out
before
then,
but
they
should
not
be
consensus,
breaking
releases,
so
obviously
an
exciting
milestone
for
us
and
for
the
five
card
project
in
general
yeah.
C
I
think
I
think,
in
terms
of
information
to
communicate,
probably
the
most
or
one
of
the
most
important
things
is
that
if
y'all
are
planning
on
syncing
the
the
chain
from
genesis
we
need
to,
we
need
to
share
info
about
our
various
irregular
state
transitions.
We'll
do
that
and
if
you
have
more
questions
about
how
we
handle
the
migration
and
just
want
to
talk
over
design
stuff,
shout
outs
out
for
that.
We've
got
a
few
other
people
who
can
who
can
share
what
we
did
so
yeah.
C
That's
about
all!
That's
that's
exciting
in
lotusland,
so
liftoff
on
wednesday
hope
everyone's
excited
and
thanks
everyone
for
being
a
part
of
this.
A
Thursday,
right
thursday
october
3rd,
this
thursday,
sorry,
I
lied
pretty
sure
it
would
be
a
day
earlier
than
I
expect.
Oh
gosh
yeah.
C
Yep,
so
quickly
on
that
lotuses,
so
the
address
structure
in
the
python
protocol
itself
does
not
know
the
difference
between
whether
you
have
a
t,
prefix
or
an
f
prefix,
and
that
is
entirely
defined
by
by
the
actual
bytes
of
the
private
key.
So
they
should
in
general
be
able
to
be
usefully
interchangeably.
C
So
right
now
on
the
network,
there
are
some
people,
who'll
be
seeing
t
addresses
some
people,
who'll
be
seeing
f
addresses,
but
they
are
the
same
thing
assuming
they're.
The
same
actual
private
keywords.
J
Awesome
yeah
so
so
for
us,
it's
been
mainly
focused
on
interop
and
we
kind
of
splitting
up
our
approach
to
interop
into
two
phases.
First,
we're
verifying
our
implementation
without
networking,
and
then
we're
going
to
attempt
to
connect
space,
race
and
sync
and
so
to
test
our
implementation.
Without
networking,
we've
been
using
an
export
from
space
race
and
testing
the
state
transitions
using
that
by
importing
those
into
forest,
and
we've
also
pulled
in
all
the
new
conformance
tests
and
now
we're
resolving
the
failing
tests.
E
E
The
reason
for
doing
it
differently
or
kind
of
in
parallel
is
because
the
chain
export
test
is
going
to
test
more
things
like
the
block
validations,
and
you
know
everything
else-
around
syncing
minus
the
networking
so
yeah
I
just
been
kind
of
making
progress
on
that
updated
all
the
the
test.
Vectors
and
a
lot
of
them
are
failing
for
basically,
the
same
reason.
So,
hopefully
you
know
once
we
resolve
the
the
state
diff,
then
we'll
be
good
to
go
with
that
and
then
yeah
that's
pretty
much
it
for
that.
J
Yeah-
and
I
guess
to
get
to
this
point-
we
we
finished
merging
the
minor
after
updates,
to
bring
us
to
093,
and
we
started
looking
at
the
the
forks
and
all
that
so
happy
to
hear
that
there
will
be
a
detailed
document
sharing
what
we
have
to
think
about,
rather
than
just
like
diving
into
the
code
but
yeah
after
we.
J
We
pass
all
these
conformance
tests
and
can
run
the
space
reset
export,
we'll
just
try
to
connect
to
space
race
and
attempt
to
sync
that
way
with
networking
and
see
how
that
goes.
J
Otherwise,
in
parallel,
we've
been
running
a
local
devnet,
so
we've
integrated
storage,
miner
and
we're
running
our
node
locally
and
seeing
what
happens
and
just
resolving
issues
as
they
come
up.
So
that's
been
happening
as
well
as
on
the
side
while
we're
working
on
interop
and
then
we're
also
working
towards
integrating
markets.
So
the
go
fill
markets
interface
is
ready
to
go
and
we're
just
working
on
the
pay
channel
and
the
pay
channel
rpc
methods
on
the
forest
side,
and
once
those
are
done,
we
should
be
able
to
integrate
with
markets
seamlessly.
C
Not
a
question,
but
if
you're
ever
yeah,
especially
when
trying
to
think
the
chain
itself,
if
you're
ever
stuck
at
a
weird
state
transition
mismatch
and
you
you
know,
feel
like
you're,
not
getting
anywhere
just
shut
us
out
because
carefully
possible,
it's
a
lotus
bug.
It
was
the
last
bug
that
y'all
would
probably
have
to
implement
because
that's
the
main
chain
now
but
yeah.
It's
certainly
possible
that
the
issue
lies.
So
that's
not
with
y'all.
B
Sure
yeah,
I
think
we
pick
up
google
falcon
two
weeks
or
three
weeks
ago,
from
perhaps
september
18th.
After
that
we
have
yeah.
B
We
have
three
engineers
to
focus
on
this
to,
to,
you
know,
want
to
make
the
kill
falcon
and
lotus
in
germany
and
in
about
one
month
and
yeah,
we
had
some
progress
and
we
knew
that
the
guru
falcon
could
do
some
kind
of
vulnerability
in
the
middle
of
june,
but
the
other
and
about
four
months
and
passed,
and
there
are
lots
of
changes,
yeah
done
and
so
yeah.
Firstly,
we
yeah
we
pick
up
this.
B
We
need
to
update
all
the
dependencies
and
many
many
packages
have
been
updated
and
yeah
have
some
new
versions
and
also
almost
all
schemas
and
all
the
data
structures
have
been
changed,
for
example,
message
and
format
and
the
block
format
and
all
of
that
and
state.
B
So
we
first
make
that
work
and
to
make
it
consistent
with
you
speak
and
they
notice
yeah
and
after
that,
okay,
two
minutes
of
code
can
be
compiled
and
can
be
drawn
and
independently.
B
And
after
that
we
will
start
to
sync
with
the
space
with
chain.
Okay,
a
very
good
progress
we
have
made
is
that
now
that
we
could
sink
the
chain
to
the
height
and
8
000
yeah
to
this
level
and
yeah,
but
and
after
this
there
are
many
things
to
do
for
us.
B
For
example,
we
know
that
first
thing
is
about
the
performance
of
all
these
things
and
that's
so
good,
including
the
virtual
machine
performance
and
the
message
and
the
verification,
performance
and
the
chance
and
performance
of
this
widow
that
we
we
we
fixed
this.
You
notice
two
in
in
the
past
months,
and
we
have
improved
a
lot
in
notice.
So
we
need
to
depend
to
do
the
same
thing
and
go
falcon,
but
we
we
want
to
say
yeah,
okay,
the
same
way
and
or
different
way,
yeah.
B
We
need
to
have
some
study
on
that,
and
also
a
very
big
thing
that
is
about
all
the
forks.
Okay,
it's
you
know.
We
know
that
the
8000
head
is
and
actually
is
before
the
first
fork
in
spaceways
and
after
that
we
have
about
four
forks
and
we
have
the
split
actors
version
2,
which
is
also
huge,
but
anyway
we
are
working
on
this
and
I
our
target
is
still
to
to
to
try
to
achieve
interability
with
yeah
with
the
current
chain.
B
Perhaps
in
a
few
weeks
and
two
or
three
weeks
and
yeah.
This
is
only
about
the
base
agent
block
and
to
sink
the
chain
to
yeah
to
to
the
latest
height.
After
that,
we
need
to,
you
know,
focus
on
the
yeah,
the
seeding
process,
the
state
machine
and
also
the
mining
process
yeah
and
the
pay
channel
the
market,
and
all
of
this
is
yeah
to
to
inter
integrate
all
this
together
yeah.
B
I
think
this
and
kind
of
what
well
we
were
done
right
now,
and
you
know
what
we
want
to
do
in
the
next
weeks.
A
Awesome
super
aggressive,
really
excited
for
progress.
You
guys
are
making
and
yeah
totally
agree,
there's
a
lot
of
stuff
that
that
changed
and
landed
in
the
last
couple
months,
as
I'm
sure
we
can
all
attest
to
so
I
appreciate
the
jumping
in
to
play
with
it.
A
A
Progress
awesome
cool!
Well,
that's!
Oh!
I
guess
the
last
bit
of
our
scheduled
agenda
was
just
talking
about
timeline
kind
of,
as,
as
all
of
you
guys,
probably
have
heard
we're
in
this
ignition
phase.
Where
we're
onboarding
a
lot
of
groups
onto
the
network.
You
know
instantiating
the
fit
process
and
starting
to
use
that
for
larger
scale,
changes
or
improvements,
and
so
can
continue
to
use
that
if
you
can
think
of
modifications
that
we
should
make
that
improve
things
and
then
we're
all
gearing
up
towards
main
net
liftoff
yeah.
A
We
definitely
do
roll
and
so
main
that
liftoff
will
kind
of.
A
We
have
a
kind
of
early
commencement
moment
with
the
initial
epoch
on
october
15th,
but
then
we're
really
going
to
have
like
a
quiet
period
of
monitoring
the
network
following
that,
just
to
make
sure
everything
is,
is
stable
and
looking
good
before
our
major
liftoff
moment,
which
will
be
october
19th
and
that
entire
week
is
a
a
week
of
kind
of
summits
and
events-
and
I
know
a
number
of
of
teams-
kind
of
around
the
world
are
going
to
be
hosting
some
events,
and
then
we
have
a
number.
A
As
well
of
talks
and
workshops
and
other
things
to
kind
of
bring
people
into
the
foul
point
ecosystem,
who
haven't
already
been
on
top
of
things
or
share
out
the
latest
work
in
improvement,
I
think
there'll
be
some
product
launches
and
other
exciting
things
to
share.
A
So
and
if
there's
anything
I
I
expect
that
you
guys
will
be
getting
pinged
for
something
from
the
implementation
side,
maybe
an
implementer's
panel
or
something
along
those
lines
to
talk
during
that
week,
from
the
19th
to
the
23rd,
so
that'll
be
cool
yeah
and
then
we're
generally
expecting
that
as
much
as
we
hope
that
you
know
after
maina,
everything
is
smooth
sailing
and
easy,
and
you
know
nothing
ever
has
to
change
again.
A
We
think
that's
unlikely.
We've
learned
a
lot
from
other
teams
who
have
gone
through
similar
release
moments,
and
we
know
there's
always
a
lot
of
stuff
that
comes
up
after
liftoff
that
is
exciting
and
challenging
and
stressful
and
so
we're
you
know,
saving
capacity
ourselves
and
generally
looking
to
those
future
moments.
As
you
know,
something
to
prepare
ourselves
for
and
make
sure
that
we
as
a
whole
community
are
ready
to
respond
and
keep
going
we're
in
it
for
the
long
term.
A
Cool
yeah
roll.
You
wanted
to
do
a
test,
vectors
update.
I
Yeah,
just
just
a
tiny
update
to
let
you
know
that
we
have
626
vectors
now
there
is
detailed
coverage
being
generated
for
each
of
the
vectors
on
the
notice
side.
So
if
you
click
through
on
the
ci
and
the
test
conformance
leading
edge
tasks
on
the
top
on
the
on
the
tabs,
if
you
go
to
artifacts
on
circle,
ci
you'll
see
a
coverage
report,
so
you
can
see
what
code
is
actually
being
tested.
That
is,
we
can.
We
expect
to
continue
increasing
the
coverage
over
the
next
few
days.
I
We
have
improved
the
tbx
tooling.
So
now
we
have
this
tool
which
anybody
can
use
to
extract
test
factories
from
any
knife
chain.
So
what
this
tool
does
is,
basically,
it
goes
into
into
a
chain
goes
into
extracts.
The
message
runs:
any
precursors,
we've
added,
that
functionality
now
runs
any
precursors
and
we
now
are
saving
the
state
tree
by
pruning
it
heavily,
so
we're
only
retaining
those
sets
that
I
actually
accessed
during
the
during
the
execution
of
the
vector.
I
I
So
this
means
on
gas
used
on
state
on
exit
code
and
so
on,
and
the
thing
that
was
that
was
missing
that
one
of
the
missing
links
that
was
missing,
there
was
the
randomness,
so
we
weren't
actually
saving
any
randomness
and
we're
just
generating
more
randomness
to
a
fixed
value,
and
this
was
derailing
the
extraction,
because
some
of
the
minor
methods
hobbies
obviously
use
real
randomness
and
they're
allowing
real
randomness.
So
this
is
now
fixed
and
to
fix
this
we've
added
a
randomness
field
on
the
on
the
test
vectors.
I
So
there's
basically
around
this.
It's
composed
of
a
set
of
matches
which
basically
you
match
on
the
input
to
the
request
of
randomness
and
you
return.
Whatever
output
is
encoded
in
the
test
vector
the
tbx
tool,
the
tbx
tool
is
already
saving
randomness
from
chain.
Another
thing
that
we
removed
as
well
were
the
fixed,
the
fake,
sick
syscalls.
So
now
we're
relying
on
real
signatures
on
a
real
unreal
cisco's
as
well,
there's
been
a
bunch
of
improvements
and
we
are
close
to
adding
around
like
another
100
vectors.
I
Today,
probably
there
is
one
missing
link
which
is
making
just
a
tiny
portion
of
vectors
generate
different
gas
usages
by
that
deviate
by
a
tiny
fraction.
So
that's
something
that
we're
investigating
right
now
by
comparing
execution
traces,
and
we
hope
to
get
to
the
bottom
of
that
today
to
nail
the
100
extraction
rate
and
the
last
bit
here
looking
forward
for
the
rest
of
the
week
and
next
week,
we'll
be
working
on
adding
support
for
network
versioning
and
all
kinds
of
versioning.
I
We
still
like
figuring
out
how
to
best
do
it.
There
was
a
proposal
to
add
kind
of
like
a
matrix,
parameter
and
vectors
so
that
you
can
test
a
given
vector
mark
vectors
for
different
network
versions
that
they
would
be
valid,
for.
I
think
in
practice
this
is
probably
gonna
not
gonna,
be
useful
for
us,
because
some
some
aspects
of
the
preconditioned
state
tree
will
change
like
the
the
actors,
sids
and
so
on.
So
we're
still
figuring
out
based
on,
like
all
the
different
versioning.
I
But
the
goal
is
to
basically
get
to
a
point
where
we
can
potentially
reuse
all
of
the
test,
vectors
that
we
that
we
have
by
either
creating
parallel
corpus
for
different
versions
by
using
a
tool
that
would
just
update
those
test
vectors
and
upgrade
them
to
the
new
versions
if
they
execute
in,
in
the
same
way
and
kind
of
like
what
a
lot
would
report
back,
which
vectors
fail
to
execute
with
with
new
versions
which
should
align
with
the
functionality
that
has
actually
changed
under
the
hood.
I
That
we
know
has
changed
so
if
we
spot
a
vector
failing
with
a
new
version
that
doesn't
quite
you
know,
make
sense
that
it
fails.
Then
we
know
that
we
might
have
introduced
a
regression.
So
these
are
kind
of
like
the
the
checks
and
balances
that
that
this
new
functionality
will
give
us.
E
Yeah
sounds
really
cool,
especially
with
all
the
diff
tool
and
everything
that
was
such
a
that
was
so
awesome
to
kind
of
find.
I
just
have
one
quick
question
about
the
because
you
said
you're
doing
basically
encoding
the
randomness
into
the
factor.
Are
you
doing
the
same
thing?
Basically
for
proof,
verification
like
verifying
postproofs
and
stuff
like
that,
or
is
that
just
not
included
in
the
coverage.
I
Yeah,
that's
that's
actually
not
included
in
coverage.
What
we
maybe
plan
to
do
is
so
this
is
really
not
for
for
extracted
vectors.
I
The
syscalls
actually
have
enough
data
to
generate
the
right
value
for
vectors
that
we've
built
that
we've
used
scripting
and
the
builder
dsl,
for
I
think
we
will
need
a
mechanism
there
and
we
will
need
to
inject
like
some
special
form
of
the
cisco
abstraction
which
is
kind
of
like
which
eventually
potentially
delegates
to
the
real
one,
but
also
captures
certain
calls
and
returns
scanned
values
to
be
able
to
simulate
different
circumstances
when
we
actually
create
test
factors
manually
right
using
the
builder
dsl.
I
This
is
like
it's.
It's
really
hard
to
create
the
kind
of
vectors
manually
that
would
that
actually
use
the
syscalls
and
verify
consensus,
faults
and,
like
verify,
see
seals
and
so
on,
to
create
them
manually
anyway,
because
to
create
all
that
state.
For
the
miner
such
that
you
know
you
you'll
have
something
to
actually
execute
that
will
make
sense
is
already
difficult.
I
So
I
think
we
might
ultimately
not
even
have
this
functionality,
because
you
know
we
already
have
a
lot
of
a
lot
of
coverage
and
a
lot
of
cases
that
we
can
extract
from
chain.
A
Awesome,
well
that
is
it
for
our
agenda.
Any
final.
B
B
I
have
one
question
about
it:
yeah
and
not
about
the
lift
off
I
wouldn't
use
bigger
to
wiggle
or
hot
and
yeah
the
last
upgrade
right
of
the
after
0.9.0
yeah.
We
need
to
have
another
one
and
I
think
yeah.
So
what
is
a
major?
B
A
Yeah
we've
talked
about
having
you
know,
hey,
why
not
get
lotus
to
1.0.0,
since
you
know
maybe.
A
Is
a
reasonable
moment
for
that
to
happen.
The
the
major
thing
that
we've
talked
about
is
adjustments
to
various
balances
for
all
the
folks
in
in
the
network,
and
so
that's
that's
kind
of
the
last
remaining
pieces.
We
don't
expect
to
have
like
you
know,
significant
functionality
getting
added.
We
really.
A
We
want
to
keep
the
the
main
that
moment
as
smooth
and
unerror
prone
as
possible,
and
so
probably
the
the
only
thing
that
we're
tentatively
planning
around
is
is
those
sorts
of
state
adjustments
to
redistribute
balances
across
the
network,
so
we're
still
we're
still
working
on
that,
but
yeah
we
aren't
expecting
to
land
any
changes
to
functionality
or
new
features
or
anything
right.
A
As
of
that
moment,
all
of
that
should
actually
be
encompassed
in
previous
upgrades
that
allow
us
to
test
things
and
make
sure
everything
is
stable
before
actually
hitting
that
upgrade
moment.
Yeah
and
then
the
thing
that's
already
encoded
in
the
network
is
changing
the
name
of
the
network
itself.
A
B
Yeah,
okay,
is
there
and
anything
about
the
verifier
will
be
in
or
yeah
that
will
be
yeah.
A
B
A
Yeah,
there's
already
a
verified
root.
Key
holder,
I
believe
in
the
network,
but
verified
clients
and
verifiers
of
verified
clients
is,
is
a
thing
that's
going
to
be
coming
after
me
in
that
launch.
So
it's
not
going
to
be
there
as
of
the
as
at
the
initial
beginning
and
generally,
the
way
that
I
mean
zx,
if
you
were
so
on,
could
probably
tell
you
a
lot
more
about
this,
but
the
the
high
level
model
there
is
that
you
know.
A
Verifier
selection
should
be
a
community
run
process
to
make
sure
that
we
have
good
diversity
and
that
you
know
there's
no
corner
on
on
that
market,
and
so
the
aim
is
to
have
a
whole
set
of
verifiers
all
come
on
at
once
and
be
able
to
verify
a
large
community
of
clients
that
are
distributed
around
regions
and
verticals
and
and
all
sorts
of
you
know,
focus
areas,
and
so
that's
all
in
the
works,
and
I
think
there'll
be
something
published
relatively
soon
about
the
the
like
high
level
process
around
it
and
the
motivations.
A
B
A
Yeah
the
plan
is
to
continue
onboarding,
more
clients
and
and
kind
of
slingshot
is
a
great
way
for
folks
to
get
on
board
on
the
network
and
the
the
plan
is
to
keep
running
that
even
after
midnight
launch.
A
Thank
you
steven
for
spending
a
late
late
night
with
us
and
have
a
wonderful
rest
of
your
week
and
see
you
in
two
weeks
when
the
the
network
is
launched,
which
is
exciting,
I
may
have
to
move
our
time
slot,
hopefully
not
because
this
is
a
optimal
time
between
all
of
our
different
time
zones,
but
just
since
it's
liftoff
week,
there
might
be
other
exciting
things
happening
that
we
need
to
move
around,
but
yeah
otherwise
super
excited
to
see
you
guys,
one
yeah
less
than
a
week
until
I
made
that
epoch
very
exciting.