►
From YouTube: VDFs and MetaProof
Description
Survey of related CryptoComputeLab projects spanning diverse domains linked by common threads of research and development.
A
Hey
my
name
is
chima
kunsan,
I'm
a
software
engineer
at
protocol
labs
and
today
I
will
be
giving
a
brief
survey
of
some
projects
spanning
diverse
domains
linked
by
common
threads
of
research
and
development.
This
is
really
at
least
two
talks
squished
into
one.
So
I
decided
to
try
to
highlight
the
themes
which
connect
all
this
work.
I'm
gonna
have
to
move
fast
to
get
through
it
all.
So
I
apologize
for
what
will
necessarily
be
a
superficial.
A
A
A
A
Another
example
comes
from
the
file
coin
domain,
if
you're
familiar
with
the
proof
of
space
time.
One
thing
we
could
potentially
do
is:
let
storage
providers
perform
their
post
on
regular
intervals,
but
only
submit
those
proofs
less
often
in
order
to
minimize
the
chain
bandwidth,
but
the
problem
is
we
need
to
be
able
to
prove
that
the
post
happened
at
the
right
time.
The
attack
is
that
the
provider
actually
throws
away
their
data
and
regenerates
it
and
they
do
all
their
posts
all
at
the
same
time
right
before
submission.
A
A
Okay,
so
this
is
the
slide
with
a
lot
of
information
about
a
computational
vdf.
You
might
have
to
just
look
at
it
and
and
see
what
you
can
make
of
it.
The
main
point
is
that
a
forward
direction,
evaluation,
which
you
can
see
in
my
diagram
here,
is
slow,
because
exponentiation
to
a
large
power
requires
many
multiplication
operations
which
your
computer
has
to
do,
but
the
inverse
direction
is
fast
because
the
return
trip
is
shorter
in
a
finite
field,
where
we
have
modular
arithmetic.
A
Important
general
concept
with
vdfs,
which
is
basically
how
much
faster,
can
an
attacker
compute
this
function
than
an
honest
party
who's
using
the
regular
function
that
everyone's
supposed
to
use
and
the
lower.
We
can
make
that
the
better
so
we're
working
with
a
company
called
supernational
and
they
have
made
an
optimized
cpu
evaluator
already,
but
we
need
to
go
even
faster
to
bring
that
amax
down
more
so
part
of
this
work
is
to
design
and
build
an
asic,
the
better
our
ace
it
can
be.
A
The
more
an
attacker
is
going
to
have
to
spend
to
try
to
get
an
even
better
asic.
So
this
is
the
hardware
computation
based
approach.
The
limitation
of
this
is
that
even
the
best
hardware
bdf
we
could
possibly
build
is
not
going
to
be
actually
optimal.
Hardware
is
always
getting
faster,
so
we're
not
gonna
get
an
amax
that
is
practically
one
and
unfortunately
that's
what
we
would
need
for
this
file.
Coin
example
that
I
gave
this
periodic
post
so
whoops.
A
This
is
where
the
idea
of
a
latency
based
vdf
comes
in.
If
we
want
to
get
an
amax,
that's
practically
one.
We
need
some
kind
of
a
hard
speed
limit.
We
can
actually
reach
so
how
about
the
speed
of
light
so
we're
working
with
a
company
called
cryptosat
and
we're
investigating
the
idea
of
a
space
pdf
where
we
would
have
secure
satellites
placed
in
publicly
known
positions.
No
rad
tracks
this.
A
So
it's
it's
fairly
discoverable
whether
they
really
are
where
they're
supposed
to
be
they'll,
generate
private
keys
in
space
and
as
long
as
those
aren't
leaked,
then
the
physical
locations
of
the
signatures
that
they
make
will
be
known.
So
we
can
establish
a
minimum
time
between
sequential
signatures.
A
A
A
So
can
we
snark
the
snark
the
historical
answer
to
that
is:
well,
it's
not
quite
so
simple
that
that
is
a
complicated
thing
to
do,
but
nowadays
it
turns
out.
Yes,
we
can
use
recursive
snarks.
I
drew
a
picture
here
that
gives
you
some
kind
of
an
idea
of
what
that
might
mean,
but
we
don't
have
time
to
talk
about
it
in
detail.
So
we'll
just
move
on.
A
So
this
is
it:
we
are
building
hardware
and
software
optimizations
for
recursive
proven
systems
we're
working
with
the
electric
coin
company,
who
you
might
know
from
z
cash
and
we're
also
using
nova,
which
is
a
proving
system
coming
out
of
microsoft's
research.
So
halo,
2
and
nova
are
two
candidate
proving
systems
they
both
use.
Recursive
snarks.
A
They
both
work
with
the
pasta
curves
and
they
use
different
arithmetizations
for
the
concern
systems,
either
way
we're
working
on
cpu
optimizations
for
verification,
gpu,
optimizations
for
off-the-shelf,
proving
and
asics
tuned
for
proving
on
these
things,
and
the
goal
is
to
make
creating
recursive
snarks
five
to
ten
times
cheaper.
So
this
should
be
good
for
everybody.
A
Founded
on
our
frustrations
with
the
limitations
of
previous
generation
snark
techniques
that
we
had
available
to
us
when
building
file
coin
with
modern,
improving
systems
on
the
cusp
of
accessible
recursion,
we
saw
an
opportunity
to
look
forward
and
metaproof
is
our
vision
for
how
to
do
that.
So
we
want
to
decouple
the
proof
specification
from
the
underlying
proving
systems
like
we
don't
write
most
of
our
software
and
assembly
or
logic
gates.
So
why
do
we
write
our
proofs?
That
way?
A
We
want
to
have
proofs
that
are
about
proofs
so
that
we
can
use
the
proving
mechanism
to
help
us
and
know
that
our
programs
are
correct.
How
do
we
know
that
our
circuits
are
actually
doing
what
we
want
them
to
do?
This
is
hard
to
do
and
we
want
to
support
general
computation,
especially
in
the
domains
of
decentralized
data.
A
What
does
that
mean?
So
the
traditional
starks
like
falcoin
has
today
are
bounded.
We
have
a
circuit
and
we
can
only
perform
a
certain
number
of
calculations
in
each
circuit
in
falcoin.
We
raise
that
limit
to
be
very
large,
but
at
the
end
of
the
day,
this
influence
is
the
form
of
the
computation
we
can
actually
perform.
A
So
we
can't
have
unbounded
loops,
we
can't
have
arbitrary
control
flow,
we
can't
have
unbounded
repression,
and
this
makes
it
hard
for
us
to
write
things
that
feel
like
normal
computer
programs
and
puts
us
in
a
box
in
terms
of
the
kinds
of
proofs
and
protocols
that
we
can
design
so
touring,
complete
snarks
overcome
these
limitations
and
everything
that
was
you
know
and
no
on
the
left
side
is
a
is
a
yes
on
the
right
side.
So
we'll
have
unbounded
arbitrary
control
flow
and
unbounded
recursion.
A
A
A
Programs
are
data
and
vice
versa,
and
the
data
is
content
addressable
for
compatibility
with
ipld
ipfs.
So
there
are
a
lot
of
approaches
to
turn
complete
snarks.
You
know
what
we're
doing
is
just
one
of
many
exciting
things
that
a
lot
of
groups
are
doing,
but
we're
especially
focused
on
the
use
cases
that
fit
with
filecoin
and
protocol
labs
is
decentralized
data,
centric
applications,
so
hopefully
we'll
have
that
available
by
the
end
of
the
year.
You
can
check
out
the
repo
and
ask
us
questions
there.
If
you
want
to.
A
A
So
this
lets
you
see
what
the
code
looks
like,
and
it
also
provides
a
minimal
example
of
something
that
turin
complete
snarks
allow,
but
that
is
impossible
with
ordinary
snarks.
So
specifically,
this
example
allows
me
to
prove
both
membership
and
non-membership
of
an
element
in
a
set
of
unbounded
size
and
the
prover
cost
is
linear
in
the
actual
sizes
of
the
set.
So
there's
a
lot
to
unpack
here,
but
if
you
can
understand
this
example,
you'll
see
many
of
blocks
addressed
interesting
characteristics.
A
The
main
thing
is,
if
you're
not
used
to
thinking
this
way-
and
you
happen
to
be
able
to
read
list
code,
then
this
just
looks
like
a
short
list
program.
That's
inspecting
some
data
and
in
fact
that's
what
it's
it,
what
it
is
and
that's
what's
interesting,
all
right,
and
so
the
list
data
is
the
same
form
as
list
code,
which
is
this
content.
Addressable
snart
friendly
ipld,
like
I
said,
a
lot
to
unpack,
but
it's
very
exciting
for
us
me
at
least
so,
hopefully
over
time
we'll
see
the
fruit
of
this.
A
So
lurk
is
very
expressive
and
legible,
as
you
saw
before.
You
might
take
issue
with
that.
If
you
don't
like
the
way
list
code
looks,
but
it's
also
a
natural
target
for
other
languages.
So
if
you
don't
like
that,
build
something
else
and
compile
down
to
it,
we
already
have
a
number
of
projects
that
are
either
starting
work
on
or
planning
to
develop
back
ends
for
lurk.
A
There's
an
internal
pl
project
called
barely,
which
is
working
on
certifiable
ipld
data
and
transformation
for
decentralized
systems
and
we're
looking
at
targeting
alert
for
that
as
well,
and
we're
also
working
with
a
language
called
glow
for
decentralized
applications.
That's
a
very
close
fit
to
have
a
zero
knowledge
proof
back
end
for
their
programming
model.
A
And
we
have
a
first
file
coin,
specific
application
in
mind
for
this,
and
this
is
verifiable
computation
over
file
coin
sectors,
which
I
think
is
super
exciting,
so
filecoin
makes
it
cheap
to
store
a
lot
of
data.
But
what,
if
you
want
to
operate
on
that
data
without
retrieving
all
of
it?
I
don't
want
to
have
to
transfer
32
gigabyte
chunks
of
data
every
time
I
want
to
perform
some
kind
of
a
query
on
my
data.
A
So
let's
say
I
have
a
database
containing
millions
of
weather
records
and
I
will
know
the
average
temperature
in
lisbon
on
days
in
2020
when
it
also
rained
a
storage
provider,
could
calculate
this
small
result
and
return
it
along
with
a
proof
of
correctness
and
if
that's
verified
on
chain.
This
is
going
to
allow
smart
contracts
to
interact
with
sector
storage,
so
for
decentralized
computation
to
be
efficient,
it
must
be
possible
to
eliminate
redundant
computation
and
colic
co-locate,
the
storage
and
computation,
and
this
is
going
to.
A
Let
us
do
that-
it's
very
early,
but
this
is
probably
the
most
exciting
application
for
me
because
it
builds
on
filecoin.
So
we're
looking
forward
to
working
with
the
falcon
virtual
machine
team,
fdm
team
to
explore
these
possibilities
and
see
what
kind
of
interactions
will
be
possible.
So
in
review.
A
We're
working
on
vdfs
with
optimized
hardware
and
software
and
we're
putting
satellites
in
space
and
through
that
investigation
of
space
and
time
we
were
driven
to
investigate,
support
and
help
develop
recursive
snarks,
and
this
allows
turn
compute
completeness.
So
we
developed
a
programming
language
that
exploits
that,
and
this
lets
us
do
many
cool
things,
many
of
which
we
don't
even
know
right,
but
one
of
them
is
verifiable,
computation
on
decentralized
data
in
filecoin,
so
watch
this
space.
The
worker
is
only
beginning,
but
it's
very
exciting.