►
From YouTube: Multiple Impls & Test Vectors by Raul Kripalani
Description
We’ll cover why having multiple Filecoin implementations is crucial, and we’ll walk through some of the tooling and resources that support conformance and interoperability testing, like test vectors.
Join us for Filecoin Liftoff Week, an action-packed series of talks, workshops, and panels curated by the web3 community to celebrate the Filecoin mainnet launch and chart the network’s future. https://liftoff.filecoin.io/
Events take place all week, October 19-23, 2020. #FilecoinLiftoff
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
I'm
very
excited
to
be
here,
it's
great
that
we're
shipping
childco
and
it's
great
that
we're
already
on
mainnet
and,
what's
even
more
amazing,
is
that
even
though
mainnet
is
mostly
running
with
lotus
right
now,
there
are
three
other
implementations
that
are
very
close
to
do
to
being
part
of
that
network
as
well.
So
I'm
going
to
talk
a
little
bit
about
why
different
implementation.
A
So
our
agenda
for
today
is
gonna,
be
first
of
all.
I'm
gonna
cover
why
multiple
multiple
implementations
is
important
for
a
decentralized
network
like
falcon
and
especially
for
blockchain.
Then
I'm
gonna
briefly
introduce
the
four
implementations
if
you
have
tuned
in
for
for
earlier
sessions
and
liftoff
in
liftoff
week,
you
would
have
already
heard
about
these.
These
implementations
and
you
would
have
heard
from
the
developers
and
themselves
so
I'm
not
I'm
not
really
gonna
focus
too
much
into
this.
A
So
the
first
thing
that
I
wanted
to
make
sure
that
we're
on
the
same
page
about
is
why
multiple
implementations
are
important
for
a
protocol
like
falcoid.
First
of
all,
having
multiple
implementations
allows
us
to
ensure
that
the
network
remains
robust
and
resilient
in
the
presence
of
bugs,
especially
in
bugs
that
are
present
in
a
single
implementation
and
when
it
really
depends
on
the
nature
of
the
bug.
But
if
the
bug
is
in
the
protocol,
if,
if
the
bug
impacts
consensus,
it
is,
it
would
be
immediately
portable
in
a
network
that
is
heterogeneous.
A
That
is
running
with
multiple
clients
that
one
particular
implementation
says
has
deviated
from
the
rest
of
the
network,
because
there
will
be
a
fork
emerging.
So
so
this
is,
it's
really
really
important
to
have
multiple,
multiple
implementations,
because
if
we
didn't,
then
the
bug
would
probably
persist
for
a
long
time,
because
we
would
have
potentially
no
way
of
noticing
it
until
you
know,
maybe
potentially
it
was
too
late.
A
A
So,
if
a
network,
so
it's
really
important
for
multiple
implementations
to
have
to
have
been
built
against
the
specification
itself
and
not
having
copied
each
other
a
lot
in
like
the
implementation
details,
so
that
potential
so
that
potential
security,
vulnerabilities
and
one
implementation
don't
actually
translate
into
another.
So
when
we
have
a
network,
that's
operated
by
multiple
by
multiple
clients,
multiple
implementations,
if
a
security
vulnerability
is
found
in
one,
it
won't
take
down
the
entire
network
as
a
whole.
A
A
It
was
developed
by
protocol
labs
and
it
also
works
hand
in
hand
with
another
project
that
we
call
specs
actors,
and
this
is
kind
of
like
the
actor
implementation
that
embeds
into
internodus
itself.
We've
got
an
implementation
written
in
rust.
This
is
called
forest
and
it's
developed
by
chainsafe.
You
would
have
heard
from
them
earlier
in
the
week
and
they
are.
A
They
have
a
heavy
focus
on
on
safety
and
also
the
the
first
ones
to
adopt
test
factory
so
kudos
to
that
and
by
the
way
I
just
got,
I
just
got
news
from
austin
yesterday.
I
think
it
is
that
they're
successfully
passing
all
test
vectors
now.
So
this
is
amazing.
There's
a
third
implementation
called
fujon.
A
This
is
developed
by
sora
mitsu
and
they
are
just
preparing
to
to
adopt
test
factories
and,
by
the
way,
underneath
each
of
these
implementations,
you
can
find
a
link
to
the
record
in
case
you
wanna
you're,
curious
to
to
explore
them
and
we've
got
another
implementation
that
has
just
joined
the
group.
It's
called
venus
and
it
was
originally
go.
It
was
originally
go
falcone,
which
was
originally
started
by
by
pl,
but
it's
now
continued
by
by
ibfs
force
and
it's
targeting
they're
targeting
interoperability
in
one
month
time.
A
So
that's
that's
amazing.
If
you're
interested
in
implementing
an
implementing
falcon
from
scratch
in
another
language
or
targeting
another
environment,
make
sure
that
you
get
in
touch
with
protocol
labs
at
five
point:
dot,
io,
slash
brands
and
potentially
apply
for
a
grant
all
right.
So
how
do
we
work
together?
As
I
said
like?
These
are
many
organizations
developing
different
clients
and
these
areas
we
are
all
distributed
across
the
globe
right.
A
So
there
are
a
bunch
of
things
that
we
do
to
make
sure
that
we
stay
aligned
we
implement,
or
we
propose,
submit,
discuss
and
review
protocol
changes
through
five
coin
improvement
proposals.
These
are
called
fips
and
you
can
you
can
look
at
them
in
in
that
link
over
there.
We
also
get
together
every
two
weeks
in
the
status
quo.
A
We
do
discussion,
we
coordinate
and
so
on,
and
these
calls
are
entirely
public,
so
you
can
watch
them
on
youtube
in
the
file
point
channel
and
also,
of
course,
we
interact
as
developers.
We
are.
We
interact,
as
through
our
user
user.
Sorry
use
what
usual
channels,
man,
what
a
day-to-day
usual
channels,
so
github
slack
and
so
on.
A
We
also,
of
course,
submit
issues
and
prs
against
the
specs
themselves,
and
also
we
have
this
new
set
of
tools
called
test
vectors
that
allow
us
to
to
verify
our
implementation,
so
I'm
gonna
focus
on
that
all
right.
So
what
are
test
factors
and
what
is
a
test
vector
so
test
vectors
have
been
incredibly
useful
to
to
get
us
all
on
the
same
page
and
to
make
sure
that
implementations
are
able
to
test
themselves
against
a
set
of
interoperable
declarative
and
fully
deterministic
test
cases.
A
A
test
vector
captures
preconditions,
inputs,
values
that
are
coming
from
the
environment
which
are
stubbed
like
randomness
and
also
that
capture
the
expected
output.
So
you
can
imagine
that
the
component
that
is
being
subjected
to
a
test
vector
is
kind
of
like
a
black
box,
say,
for
example,
the
vm,
the
file
coin
vm
and
the
test
vector
tells
you
how
to
prepare
the
environment,
what
to
feed
as
an
input
and
what
the
output
should
be
from
that
black
box.
A
So
this
allows
us
to
test
the
correctness
and
conformance
with
a
falcon
specification
and
also
the
interoperability
with
other.
What
other
implementations?
An
important
thing
is
that
test
vectors
are
never
crafted
manually,
they're,
never
written
with
with
fingers
right.
They
always
generally
generated
with
tooling.
They
can
be
generated
from
ideally
any
falcon
implementation
right
now,
they're
being
generated
from
lotus
and
there's
two
ways
to
create
test
factors.
A
I'll
talk
about
that
in
in
a
second
test
factories,
you
can
think
of
test
vectors
as
kind
of
like
a
thing
that
captures
a
photograph
that
captures
what
behavior.
That
is
true
in
one
implementation,
so
that
it
can
be
verified
in
other
implementations.
So
essentially,
they
they
serve
as
functional
test
cases
to
begin
with,
but
then
they
survive
as
regression
tests
going
forward.
A
So
some
of
the
challenges
that
are
addressed
by
test
vectors
is
first
of
all.
We
need
a
way
to
capture
how
a
system
behaves
given
a
specific
message
or
a
specific
tip
set
or
a
specific
block,
because
the
way
that
an
implementation
behaves
should
be
exactly
the
same
across
all
implementations
as
we
accumulate
a
corpus
or
body
or
a
body
of
test
vectors.
It
also
allows
us
to
catch
inadvertent
consensus,
breaking
changes
that
we
make
to
the
to
the
implementation.
A
A
All
of
these
changes
and
it's
important
that
the
test
vector
by
the
test,
vector
corpus,
is
also
storing
and
memorizing,
all
those
all
those
behaviors
that
were
captured
across
in
a
long
time
right
so
test
factories
allow
us
for
they
award
us
with
reliable,
deterministic
and
interpret
interoperable
conformance
testing.
So,
basically,
we
write
a
test
vector
once
and
we're
capable
of
running
it
against
all
implementations.
A
The
alternative
to
this
would
be
for
each
and
every
implementation
to
write
the
same
test
over
and
over
again,
and
this
also
has
been
having
a
body
of
test.
Vectors
has
also
been
super
important
to
avoid
what
I
personally
call
big
bank
testing
when
you're
implementing
a
system
from
scratch,
you're
implementing
a
blockchain
clone
from
scratch.
There
are
a
lot
of
components
that
make
a
blockchain
client
right.
There
is
the
network.
There
is
the
chain
itself.
There
is
the
store
there
is
the
vm.
A
We
also
want
to
be
able
to
attach
test
cases
and
and
test
vectors
to
file
on
improvement
proposals
right
so
enough
about
kind
of
like
the
fundamentals
and
the
motivation,
and
so
on.
Let's
talk
about
what
a
test
vector
looks
like
in
reality.
This
is
what
you
see
on
screen.
Right
now
is
an
example
of
a
test
vector
the
test
vector
as
we've
implemented
them
in
in
file
called
in
the
filcon
project.
A
A
A
It
also
defines
variance
diagnostics,
and
we
also
include
the
state
tree
and
particular
slices
of
the
state
tree
as
a
base64
gcept
gzip
string
in
the
vector
itself.
So
the
corpus
of
test
vectors,
which
is
the
book
of
all
the
test
vectors
that
exist
right
now,
is
composed
of
850
vectors.
Right
now
and
counting.
There
are
three
classes
of
vectors.
There
is
the
message
class
vector
which
targets
the
vm.
A
A
So,
just
to
give
you
kind
of
like
the
bird's
eye
view
of
how
we
build
the
test
vector
system
on
the
left
hand
side
of
this
diagram.
You
see
how
vectors
are
generated
so,
as
I
said,
generated
by
reaping
them
from
a
network
or
by
crafting
them
using
a
dsl
and
on
the
right
hand,
side.
So,
okay,
so
these
two
things
actually
create
vectors
and
then
vm,
implementations
and
file
coin
implementations.
A
All
they
need
to
do
is
implement
a
driver
that
is
going
to
consume,
that
test,
vector
and
subject
their
components
under
the
circumstances
and
situations
described
by
by
that
test
vector.
So
just
to
give
you
an
example
of
how
a
test
vector
is
built
in
the
generative
way.
So
this
is
writing
crafting
it
using
the
dsl.
This
is
a
simple,
a
simple
example
which
basically
sends
a
transfer
from
unknowns
from
an
unknown
sender
and
a
known
receiver,
and
what
we
are
testing
here.
A
So
there's
three
phases:
there
is
a
precondition
phase
where
we
create
the
accounts
and
we
create
the
state
tree
on
which
that
vector
is
going
to
run.
Then
we
create
the
the
applies.
So
the
things
that
are
actually
going
to
be
applied
so,
in
this
particular
case,
a
transfer
and
then
there's
a
third
stage,
which
is
the
assertion
stage
where
we
verify
where
we
verify
that
certain
conditions
are
met,
and
one
important
thing
is
that
the
protocol
evolves
over
time.
A
So
each
of
these
vector
scripts
are
don't
just
generate
one
vector
that
generate
many
vectors
that
generate
a
vector
for
each
known
protocol
version,
so
genesis,
breeze,
smoke,
ignition
actors
version
two.
If
you've
been
following
the
history
of
the
chain.
Now
these
germs
will
be
familiar
to
you
and
we
also
have
a
mechanism
in
place
to
coalesce
and
to
merge
vector
variants
that
are
identical
in
their
preconditions,
post
conditions
and
so
on.
A
There
are
certain
conditions
that
we
wanna,
that
we
wanna
be
able
to
test
that
are
not
present
in
the
production
code,
but
we
wanna,
isolate
and
be
able
to
test
specifically
and
to
do
that.
We
deploy
a
special
actor
that
we
call
the
chaos
actor,
which,
whose
role
is
exactly
that
to
wreak
chaos
right
so
vectors
that
use
the
chaos
actor.
A
A
A
So
in
case
you're
curious,
you
can
take
a
look
and
it
allows
us
to
basically
cherry
pick
and
message
from
the
chain
and
generate
a
test
factor
out
of
it,
and
it
does
some
interesting
things
if
we
were
to
so
say,
for
example,
right
now
the
chain
is
at
height,
170,
000,
or
something
like
that.
If
we
were
to
like
have
to
extract
the
entire
state
tree
to
be
able
to
run
one
message,
that
vector
would
be
gigabytes
big
right,
so
we
can't
do
this.
So
what
the
well,
what
the
tool
does
is?
A
It
marks
masks
the
state
tree
filters,
the
state
tree
such
that
we
only
retain
actors
or
ids
that
were
effectively
accessed
during
the
execution
of
the
particular
thing
that
we're
applying,
whether
it's
a
message
or
a
tip
set
or
whatever
and
I'll
show
you
a
demo
on
of
of
how
this
works
in
a
few
minutes
now,
one
thing
so
you
saw
you
so
kind
of
like
saw
what
the
test
vector
looks
like.
It
includes
a
lot
of
binary
data
and
the
state
tree
is
not
precisely.
A
A
So
if
you
apply
test
spectrum
and
happens
to
fail
because
the
post
conditions
are
not
met,
you
need
a
way
to
be
able
to
dig
into
what
that
vector
expected
and
what
is
it
that
your
implementation
actually
generated
and
how
it
deviated,
how
those
two
things
deviated
from
each
other
right.
So
we
created
a
tool
to
go
along
with
this
entire
suite
called
statif
and
it
uses
a
library
called
go
comp
along
with
ipld
schemas
to
traverse
and
recurse
the
state
tree,
and
it
has
two
modes
of
operation.
A
Given
a
car
and
two
root
c
ids,
they
can
compare
the
state
trees
anchored
at
those
routes
inside
the
car.
A
car
by
the
way
is
a
content
archive,
so
it's
basically
a
way
of
storing
an
ipld
repository
inside
a
file,
and
it
also
has
a
second
mode
of
operation
which
is
given
a
vector,
compare
the
precondition
and
the
post
condition
state
trees.
A
My
colleague
will
who
has
been,
will
scott,
who
has
been
working
on
state
div
and
he
basically
owns
all
of
stick.
Diff
is
gonna,
give
a
talk
later
so
make
sure
that
you
tune
in
because
it's
super
interesting
what
this
project
is
doing
and
as
well.
The
other
tools
that
these
pro
that
that
state
div
has
catalyzed
like
state
explorer
and
state
dump
and
he's
gonna
cover
them
later
on.
A
Who
doesn't
have
that
dream
and,
as
I
said
earlier,
this
screenshot
is
outdated
because
it
shows
only
564
test,
passing
where
there
is
a
lot
more
now
so
800
and
something-
and
this
is
a
screenshot
from
the
forest
ci
running
the
test-
vectors
right
now,
they're
passing
all
test
vectors
so
kudos
to
them.
That's
amazing.
A
There
are
other
tools
that
that
kind
of
like
surround
the
psychosystem
of
testing
within
five
coin:
state
def
and
state
down
already
covered
state
div.
What
you
see
there
is
a
it's
a
screenshot
of
of
state
explorer.
This
slide
should
say
explorer,
which
is
a
project
that
will
is
going
to
talk
about
as
well
in
in
a
few
hours,
and
then
we
also
built
so
if
you've
been
following
kind
of
like
the
developments
in
projects
at
protocol
labs
you'll
have
seen
a
project
emerge
a
few
months.
A
I
think
it
was.
I
think
we
launched
it
in
may
this
year
and
it's
called
test
ground,
and
this
is
basically
a
platform
to
allow
us
to
test
the
period
of
year
and
decentralized
systems
at
scale
and
we've
iterated.
On
top
of
that
to
build
what
we
call
test
run
as
a
service,
which
is
a
continuous,
continuous
testing
facility
and
anton
by
the
way
anton
is
gonna
is
gonna.
Talk
is
gonna
cover
this
as
well.
A
My
colleague
anton
we've,
been
working
together
very
closely,
he's
going
to
cover
tesco
as
a
service
in
a
few
hours
as
well,
so
make
sure
that
you
tune
in
to
to
to
that
one
all
right.
So
it's
time
for
demos,
I'm
going
to
show
a
few
things
here,
so
I
want
to
show
first
of
all
running
conformance
tests
on
lotus,
I'm
going
to
show
running
a
single
vector.
Then
I'm
going
to
show
extracting
a
test
vector
and
I'm
going
to
show
state
def
and
I'm
going
to
show
statistics
in
two
different
ways.
So.
A
Window
moving
here
and
there
it
is
all
right,
okay,
cool,
so
first
thing
that
I
wanna
show
is
running
running
the
conformance,
so
within
lotus
in
the
lotus
repository
there
is
a
git
submodule
that
imports
the
test
vectors
and
inside
the
corpus
directory.
You
will
find
you
will
find
all
the
test
vectors
here
right.
So
the
conformance
package
and
lotus
runs
the
the
vector.
So
I'm
gonna
run
that
suite
and.
A
A
This
is
usually
important
for
test
vectors
that
have
been
extracted
from
chain
right
and,
and
you
get
the
gist-
I'm
not
going
to
wait
until
the
end,
but
it
takes
around
50
seconds
or
60
seconds
to
compete,
and
this
is
2006
test
cases
that
are
running.
So.
The
next
thing
that
that
I
wanted
to
show
you
is,
if
I'm
able
to
get.
A
My
browser
opened
right,
so
we're
gonna
pick
a
message
from
chain,
and
this
is
phil
fox-
is
one
of
the
many
blockchain
explorers
that
exist
in
the
file
for
an
ecosystem.
So
I'm
gonna,
I'm
just
gonna,
go
a
bit
behind
to
a
previous
tip
set
like
say,
for
example,
this
one
just
in
case
my
client
is
not
synced
entirely
and
I'm
gonna
pick.
The
first
message
on
this
tip
set
say
that
there's
something
special
about
this
message
that
I
wanna
that
I
wanna
memorize
into
a
test
vector.
A
So
I'm
gonna
replace
the
cid
of
the
message
by
the
cid
of
the
message
that
I
just
picked
from
jane
and
then
I'm
gonna,
I'm
gonna,
add
the
one
of
the
blocks
where
this
message
is
present
in,
and
this
allows
us
to
go
into
that
message
very
of
my
my
blockchain.
My
client
has
fallen
behind,
so
I'm
gonna
go.
I'm
gonna.
C
B
A
So
what
this
is
doing
is
it's
recording,
so
it
was
very
fast.
What
this
is
doing
is
it's
basically
finding
any
messages
on
that
block
that
were
sent
by
the
same
sender
and
and
then,
if
there
were,
there
was
zero
precursors
in
this
case
and
then
it's
reproducing
that
message:
recording
randomness,
recording
beacon
and
chain
randomness,
and
also
the
sets
that
were
effectively
accessed,
and
this
is
the
vector
that
it
outputs
I'll
say:
I'm
gonna
do
it
again,
but
I'm
save
it.
I'm
going
to
save
it
into
vector.json.
A
So
you
will
see
that
the
vector
vector
is
here
right.
Another
thing
that
I
wanted
to
show
you
was
executing
a
particular
test
vector,
so
this
is
a
test
vector
that
I
want
to
execute
against
this
implementation.
Tbx
has
a
command
that
allows
us
to
pick
a
vector
and
execute
it
against
the
implementation,
and
this
was
really
really
quick.
You
can
see
that
the
vector
succeeded
for
the
genesis
fork
for
the
breeze
fork
and
for
the
smoke
fork
and
for
the
ignition
fork.
A
So
imagine
that
now
I
wanna
have
a
look
and
see
at
the
differences
in
that
test,
vector
that
we
extracted
earlier
from
jane.
I
want
to
see
what
things
in
the
state
were
effectively
altered
by
that
vector
using
state
diff
and
using
the
vector,
sub
command
and
providing
the
the
vector,
which
is
this
one
over
here.
I
should
be
able
to
see
that
so
stick
to
if
you
go
we're
going
to
do
a
color
div
to
get
a
better
output,
and
you
see
that
this
particular
vector
is
changing
the
balance.
A
A
A
Great,
so
you
see
that
we
also
have
knowledge,
changes
and
and
some
other
changes,
but
you
see
that
we
have
a
new
actor
being
created
here,
so
that
is
consistent
with
what
the
vector
is
doing.
Of
course,
if
a
vector
fails
at
any
point
in
time,
we
automatically
print
the
state
diff
inside
our
ci
jobs,
all
right.
So,
just
before
I
wrap
up,
I
wanted
to
talk
about
the
the
future
of
tip
of
of
test
factors.
A
We're
also
introducing
a
new
class
of
vectors
called
block
sequence
vectors,
which
basically
define
a
sequence
of
blocks
that
arrive
at
specific
times
against
the
sinker
and
at
the
end
of
it.
The
post
condition
is
that
the
head
of
the
chain
should
match
a
particular
head.
This
allows
us
to
test
potential
fork
emerging
emerging
in
potential
forks
emerging
in
the
network
and
also,
of
course,
we're
enhancing
vector
coverage.
A
We
have
just
started
a
bug:
bounty
program
for
research,
for
research,
sorry
for
security
researchers
to
identify
security
issues,
so
make
sure
that
you
use
test
vectors.
If
there's
a
particular
behavior
that
you
find
that
could
be
attacked,
exploited
or
whatever,
and
you
want
to
submit
submitted
for
to
be
eligible
for
a
bug.
Bounty.
Then
a
really
nice
way
of
making
that
submission
would
be
to
capture
that
input
that
provoked
that
security
vulnerability
to
to
to
trigger
as
a
test.