►
From YouTube: Future Directions for SNARK
Description
Filecoin is focused on improving and optimizing SNARKs, not only for itself, but also for many other critical applications. zk-SNARKS have tremendous potential to scale blockchains and provide privacy in on-chain transactions. Get an update on all the areas Filecoin is utilizing and improving SNARK, including scaleable proving system SnarkPack.
A
Hi
everyone
I'm
anka
from
cryptonetlab,
so
I'm
research,
scientist
and
I'm
working
on
cryptography
on
snacks
from
five
point.
So
I
will
talk
today
about
some
recent
work.
We
did
about
snacks
in
filecoin
and
later
on,
on
this
presentation.
Rosario
will
take
over
and
talk
about
future
directions
in
this
area.
A
So
we
all
know
that
in
falcon
we
have
proof
of
storage
and
the
proof
in
this
is
done
by
this
powerful
tool
that
I
will.
I
will
present
today,
the
snacks
so
to
have
a
little
bit
of
terminology.
The
miners.
The
storage
providers
in
in
the
network
are
responsible
of
onboarding
storage
capacity
and
they
they
do
it
to
earn
blocking
words,
so
they
have
to
regularly
prove
that
that
storage
and
we
will
call
them
provers,
as
in
in
the
cryptography
protocol
for
proof
systems
on.
A
On
the
other
side,
we
have
the
nodes
in
the
network
that
need
to
check
the
validity
of
such
proofs
so
to
ensure
that
the
data
is
being
stored
and
maintained
and
secured
as
expected.
So
those
are
the
very
files,
so
we
need
to
to
find
a
way
to
improve
storage
in
an
efficient
way.
In
a
scalable
way
and
that
that
was
done
by
the
help
of
this
cryptographic
tools,
cryptographic,
primitives
known
as
zika
snacks
and
their
name
comes
from
saxon
non-interactive
argument
of
knowledge
and
the
zika
influences
from
zero
knowledge.
A
So
what
are
these
proof
systems?
They
are
perfectly
fitted
for
a
distributed
system
as
file
coin,
because
they
have
very
short
proof
size,
so
they
can
fit
in
blocks
in
the
chain.
They
are
non-interactive,
so
they
don't
require
any
extra
communication
between
the
approval
and
the
verifier
of
such
a
proof.
Just
publish
the
proof
and
the
verifier
can
come
and
check
it.
There
are
arguments
in
the
cryptographic
sense
of
security,
so
their
soundness
holds
with
respect
to
malicious
approvals
that
are
computationally
bounded
and
there
are
even
more
than
that.
A
They
have
this
knowledge
soundness
property,
which
means
that
whatever
approval
has
to
shown
that
a
statement
is
valid.
It
also
shows
that
it
knows
a
witness
for
the
validity
of
that
statement.
So
it
knows
all
the
process
for
computing,
something
not
only
the
result,
and
we
can
also
add
a
excel
property
that
we
like
for
privacy.
A
A
Any
storage
provider
has
to
divide
their
storage
capacity
into
this
partition
of
32
gigabytes.
That
will
be
later
on
encoding
in
a
more
complicated
way.
I
will
not
detail
this
here
and
the
the
storage
is
proven.
This
valid
encoding
of
available
storage
is
prove
approved,
with
10
snipes,
with
10
proofs
for
each
32
gigabytes.
A
So
we
have
to
submit
this
next
to
the
chain
and
at
some
point
we
will
have
too
many
too
many
snacks,
even
if
they
are
succinct
they
will
the
the
block.
The
current
block
will
be
filled,
filled
up
with
snacks,
so
we
need
to
to
find
a
way
to
scale
well
those
snacks.
So
it
used
to
be
that
we
have
an
onboarding
limit
of
40
petabytes
per
day
of
storage
because
of
these
snacks
that
were
accumulating
in
the
block.
A
The
verification
of
these
nuts
also
takes
time.
So
what
we
do
when
we
have
many
snacks
before
finding
a
solution
for
scalability,
we
still
had
a
way
to
make
the
verification
fast
by
batching
it.
So
a
very
file
in
the
network
will
take
a
lot
of
proofs
a
lot
of
snipes
with
them,
so
it
will
be
long
but
merge
them
together
in
order
to
verify
them
all
together
at
the
single
board
and
what
we
are
doing
now
with
smartpak.
A
A
A
As
I
said,
the
the
public
parameters
are
generated
already
from
existing
ceremonies
from
falcon
and
z
cache,
and
this
is
also
the.
This
combination
is
also
available
in
a
code
and
the
benchmarks
look
really
nice,
so
the
proof
size
compared
with
the
batching
which
grows
linear
in
the
number
of
proofs.
You
have
to
look
at
as
a
verifier.
Is
it's
really
small?
It's
logarithmic,
so
more
snacks.
We
have
to
aggregate
together
a
better
proof
size
we
we
achieve.
A
Then
we
have
the
verification
time,
which
is
very
nice
compared
to
to
batching
techniques.
So
we
see
here
that
verifying
more
proofs
doesn't
grow
in
in
inefficiency.
So
we
have
the
aggregation
time.
Also:
approval
who
wants
to
aggregate
many
snacks,
for
example
two
to
the
17
proofs,
we'll
do
it
in
two
minutes
and
we'll
onboard
a
very
small
proof
on
chain
what
to
do
next
about
this.
So
we
have
still
room
for
some
optimization
and
we
are
working
on
either
more
theoretical
version
of
snipe
back,
but
also
some
implementation,
optimization.
A
Also
we.
We
would
like
to
upgrade
these
techniques
to
transfer
integration.
What
I
mean
by
transparent
there
are
new
snarks
out
there,
which
don't
require
any
trusted
setup.
So
we
would
like
also
to
have
a
way
to
aggregate
them
without
justice,
setup
or
or
different
techniques
that
don't
require
this
and
we
will
keep
them.
B
Hi,
yes,
hi,
I'm
rosario
gennaro,
I'm
also
part
of
crypto
netlab.
So
ankara
can
you
move
to
the
next
slide
yeah.
So
let
me
briefly
say
what
kryptonet
is
working
on
to
continue
to
improve
our
snark
offerings
on
faultcoin
and
I'm
gonna
touch
on
four
specific
topics:
better
vector
commitments,
recursion
snark,
vm
and
more
applications.
B
So
can
we
go
to
the
next
slide?
Okay,
so
let
me
let's
go
back
to
what
anka
was
talking
about
the
proof
of
storage.
The
way
proof
of
storage
works
in
currently
is
that
you
have
this
32
gigabytes
that
you
can
think
of
as
blocks
that
they're
committed
into
us
much
smaller
digest
when
what
we
use
for
this
commitment
is
a
classic
cryptographic
technique
called
the
merkle
tree
and
what
the
snark
basically
proves.
Remember.
Anka
said
that
proves
knowledge.
B
What
the
snark
proves
is
that
I
know
enough
blocks
in
this
big
digest
that
you
can
see
in
in
in
the
commitment
on
chain.
So
and
so
one
question
that
we're
working
on
is:
can
we
find
better
vector
commitments
that
allow
this
proof
of
knowledge
to
somehow
be
more
efficient?
That
means
a
smaller
circuit,
a
smaller
prover
overhead,
in
terms
of
how
long
it
would
take
to
produce
this
proofs
and
how
computation
intensive
it
is
to
produce
these
proofs
next
slide.
Please
another
question
is
that
we
will
be.
B
We
would
like
to
be
able
to
reuse
this
packed
proofs
that
anka
talked
about.
So
one
thing
that
anka
mentioned
was
that
current
proofs
have
this
ver
this
format.
There
are
three
group
elements
in
a
cryptographic,
some
some
group
there's
a
b
and
c,
and
that's
a
proof,
there's
three
elements,
and
so
then
we
have
a
vector
of
these
proofs.
B
The
problem
is
that
this
commitments,
a
b
and
c
to
the
vectors,
are
now
in
a
different
group
g,
prime,
not
the
original
group
where
the
vector
came
came
from
and
these
pack
proofs
cannot
be
fed
into
another
packing
procedure
later
on.
So
the
once
you
pack
them
it's
done.
So
what
we
would
like
to
have
is
a
vector
commitment
that
doesn't
change
from
one
group
to
another
so
that
we
could
be
reused.
It
turns
out
that
in
the
most
general
form,
this
is
actually
impossible
to
achieve.
B
So
it's
not
like
we're
looking
to
you
know,
prove
something
that
cannot
be
done,
but
we're
trying
to
maybe
find
a
efficient
way
to
map
one
group
into
the
other
and
one
commitment
to
the
other.
That's
okay!
You
can
move
ahead,
so
there
is
a.
This
is
a
more
general
issue
which
is:
can
we
break
computation
into
smaller
chunks
and
verify
them
independently
and
use
the
result
of
verified
computations
as
input
for
other
computations?
B
In
particular,
there
are
two
systems
that
right
now
are
the
state-of-the-art
one
is
alo2
from
zcash
and
another
one
is
nova
from
microsoft,
research,
but
there's
more
and
there's
a
lot
of
research
in
this
idea
of
recursion
for
for
snarks,
and
we
are
trying
to
figure
out
what
is
the
best
way
to
use
recursions
in
the
kind
of
proofs
that
happen
in
this.
This
particular
proof
of
space.
That
happens
in
five
point.
So
next
slide.
B
Okay,
and
all
of
this
is
going
to
eventually
come
up
into
a
virtual,
you
know
into
a
snark
virtual
machine,
and
what
do
I
mean
by
that?
So
what
we're
trying
to-
and
this
is
not
just
falcoin
the
entire
community
is
trying
to
is
moving
towards
this
direction-
is
that
we
want
to
remove
the
snare
casper
out
of
the
picture.
We
would
like
to
be
able
to
program
code
that
in
any
programming
languages
solidity
of
javascript
smart
contracts
that
they
would
immediately
compile
to
a
verified
computation.
B
So
you,
you
shouldn't,
be
relying
on
cryptographic
experts
to
build
a
snark
for
your
computation.
There
should
be
a
system
where
you
cook
you
code
it
and
it
gets
compiled
into
something
that
produces
a
result
and
a
proof
of
the
correctness
of
that
result
and,
of
course
the
biggest
challenge
here
is
to
make
it
scalable
in
when
you
have
a
very
large
problem.
B
So
we
have
sort
of
the
weight
of
we're
thinking
about
this
problem
problem.
Sorry,
is
we
have
sort
of
divided
into
three
parts?
One
is
the
front
end.
How
do
we,
what
kind
of
language
is
best
suited
to
be
mapped
to
a
vm
instruction
set?
That
can
be
then
optimized
to
build
circuits
that
can
be
used
inside
of
snark,
and
some
of
you
may
have
seen
the
lurk
metaproof
talk
earlier
in
the
orbit
conference,
which
is
something
that
the
cryptocompute
lab
is
working
actively
to
build.
B
Then
this
this
front
end
would
be
fed
into
what
we
call
a
middleware,
which
is
exactly
all
these
techniques
to
aggregate
and
recurse
on
proofs
that
comes
from
different
subroutines.
So
if
you
write
code
that
a
subroutine,
you
would
like
to
verify
each
subroutine
individually
and
then
combine
these
proofs
of
correctness
into
a
single
proof,
similar
to
what
we're
doing
for
snark
pack,
but
now
for
a
general
computation
and
a
big
challenge.
A
big
technical
challenge
comes
from
memory
management.
B
What
I
mean
by
memory
manager,
you
need
to
somehow
prove
that
the
way
you
change
memory
is
correct.
You
know
what
you
write
and
what
you
read
from
memory
is
correct,
and
this
can
be
done
also
via
efficient
vector
commitments
and
then
the
back
end
is
what
is
the
best
cryptographic
proof
system
that
is
going
to
fit
into
all
of
this,
and
I
think
one
more
slide
and
just
an
example
of
how
also
we're
thinking
ahead
to
other
possible
applications
that
we
can
bring
in
with
snarks.
B
One
possible
thing
here,
give
you
it's
a
very
powerful
tool,
and
let
me
give
you
an
example
of
what
we
would
like
to
build.
We
would
like
to
build
the
ability
to
communicate
confidentially
through
a
secure
channel
for
people
who
know
something
so
think
of
for
falcon.
The
ideal
applications
would
be
think
of
ipfs,
and
I
I'm
going
to
announce
that
I
want
to
talk
confidentially
to
the
owner
of
a
particular
file.