►
From YouTube: VDFs and Filecoin - Jeromy Johnson
A
So
proof
of
replication
for
those
who
are
unfamiliar
is
a
slow,
unique
encoding
of
some
input.
Data
can
be
any
data.
It
protects
against
deduplication
attacks.
This
is
important
when
you're
like
giving
people
some
resource
based
on
the
number
of
reps,
because
they
have
and
in
the
context
of
the
proof
of
space-time,
this
protects
against.
What's
called
the
generation
attack
the
way
it
kind
of
works?
Is
you
take
a
file
you
break
it
up,
put
it
into
and
you
map
it
onto
a
graph.
A
You
encrypt
it
based
on
the
edges
of
the
graph,
which
is
an
inherently
like
sequential
operation,
and
then
you
use
the
outputs
of
that
to
create
your
replicas,
it's
kind
of
like
a
CBC
mode
encryption
except
more
robust
against
removing
random
those
in
the
graph
and
regenerating
things,
and
in
order
to
slow
this
down,
you
can
add
more
layers
to
the
graph
and
make
it
even
more
sequential,
and
so
the
main
the
main
thing
this
helps.
The
timing
assumption
here
helps
protect
against,
is
what's
called
a
generation
attack.
A
So
imagine
you
have
an
honest
person
and
an
attacker,
and
you
have
some
verifier
the
verifier
send.
It
sends
a
challenge
to
each
person.
The
attacker
doesn't
have
the
data,
so
they
haven't
done
the
the
seal.
They
haven't
made
the
replicas,
but
the
honest
person
has
so
when
they
receive
the
challenge.
The
honest
person
can
immediately
process
the
challenge.
While
the
attacker
has
to
start
doing
this
slow
encoding
operation,
the
honest
person
can
respond
immediately,
while
the
attacker
still
has
to
continue
doing
this
slow.
A
Basically,
this
whole
process
is
slowing,
forcing
you
to
slow
down
and
encoding
such
that
if
you're,
trying
to
recompute
the
encoding
on
the
fly'
you
get
caught
and
so
we'll
take,
some
inputs
produces
an
output
after
prescribed
time,
the
same
inputs
always
produce
the
same
output
and
the
verifier
can
efficiently
check
that
it
was
done
correctly.
This
is
done
with
some
like
snark
Merkel
proof
magic,
which
is
actually
the
fast
part
about
the
whole
thing,
and
so
that's
kind
of
one
way
that
we're
like
it
is
a
video
and
you
can
keep
it.
A
You
can
prove
you
can
slow
down
the
the
attacker
even
more
by
this
graph.
Here
is
actually
each
of
those
edges
is
a
an
encryption
operation,
and
what
you
can
do
is
the
key
derivation
function
for
each
of
those
lines
can
itself
be
a
PDF,
and
so
you
can
take
it
as
an
input
run
it
through
a
vdf
like
if
we
have
a
nice
fast.
You
know
exponentiation
vdf
and
then
use
that
as
the
encryption
key
for
the
next
node.
A
A
A
The
main
thing
we're
trying
to
prove
here
is
that
the
space
that
you're
claiming
to
have
wasn't
reused
for
some
other
purpose
during
the
time
period
that
you're
proving
it
to
us,
has
a
non-interactive,
succinct
output
or
it's
not
interactive
and
has
a
synced
output,
and
it
must
not
be
computable
too
much
faster
than
the
expected
duration
kind
of
sounds
familiar.
So
the
way
this
briefly
works
is
you
have
some
time
period.
You
have
some
input
challenge
and
then
the
prover
takes.
A
That
challenge
does
some,
like
merkel,
proofs
on
their
entire
storage,
then
takes
the
output
of
that
into
a
PDF
slows
them
down.
Does
some
more
challenges
and
other
BDF
another
PDF.
You
get
a
keep
doing
that
and
at
the
end,
you
gather
all
this
together
and
you
have
to
compute
a
proof.
You
know
we
snark
it
up,
and
then
you
submit
that
to
the
chain,
and
so
what
what
we're
doing
here
is
we're
trying
to
make
sure
that,
like
ideally,
this
entire
thing
would
just
be
these
challenges
like
entirely
consist
of
proving
to
me.
A
You
have
ranted
pieces
of
file.
The
problem
is
you
can't
prove
that
in
a
snark
efficiently,
and
so
we
lower
the
number
of
actual
challenges
that
you
have
to
do
and
replace
that
time
with
something
that
takes
a
verifiable
amount
of
time,
and
so
you
can
lower
lower
that
a
bit,
because
these
challenges
can
be
done
really
arbitrarily
fast
and
are
like
almost
cashable.
If
you
have
enough
space
so
adding
this
slowness
in
here,
the
attack
is,
if
somebody
can
do
this
much
much
faster
they
could
take
and
if
they
could
do
the
entire
thing.
A
In
this
amount
of
time,
then
they
could
wait
until
the
very
end,
regenerate
all
their
data
and
then
just
do
it
here,
and
so
for
the
rest
of
the
time.
They
could
be
reusing
this
space
for
saying
they
have
all
sorts
of
other
storage,
which
is
bad,
and
so
what
we
can
also
do
here,
instead
of
having
each
of
those
blue
lines,
be
a
PDF
or,
in
addition
to
those
blue
ones.
Being
with
you
death.
A
Who
knows,
we
have
a
random
beacon
that
is
made
with
constructed
out
of
EDF
and
use
the
output
of
the
random
beacon
and
each
set
to
reseed
these.
So
this
whole.
This
means
that
if
you
have
an
advantage,
you
can't
you
can't
complete
this
early.
You
have
to
wait
at
least
until
the
very
last
random
beacon
element
is
known
and
then
you're
able
to
complete
it,
and
so
combining
this
with
a
random
beacon,
basically
allows
you
to
prevent
an
attacker
from
going
arbitrarily
fast.
This
whole
process
does
look
a
lot
like
a
PDF.
A
A
A
A
Obviously,
that's
really
really
impractical
and
the
expense
of
doing
that
and,
like
the
hardware
required
to
do
that,
would
be
absurd,
but
just
keeping
this
vdf
in
here
makes
that
much
more
expensive
and
makes
it
much
more
unlikely
that
you'll
be
able
to
pull
that
off,
and
it's
it's
not
strictly
necessary,
but
it
does
like
this
is.
This
is
a
game
of
increasing
the
costs
for
an
attacker?
A
That's
all
this
is
we're
just
trying
to
make
an
attacker
have
to
spend
a
lot
more
money
to
beat
us
like
the
whole
vidya
thing
is
that
so
then
yeah
then
the
third,
the
third
like
piece
we're
looking
at
is
our
consensus
mechanism,
which
elects
on
expectation
one
leader
per
round,
which
is
why
it's
called
expected.
Consensus
includes
all
blocks
in
the
previous
round
as
parents
it's
and
it's
kind
of
like
a
proof
of
stay
key
consensus
protocol
and
one
the
thing
we're
exploring
is
a
lot
of
these
protocols.
A
You
can
look
look
into
the
future
to
see
the
randomness
generated
like
if
you
went
this
block.
If
you
wanted
this
block,
if
you
want
this
block
and
a
way
to
prevent
people
from
looking
into
the
future
in
these
is
just
forcing
the
computer
PDF
between
every
block.
This
is
only
more
useful
if
you
have
a
like
a
very
strong
PDF,
because
these
is
like
30
seconds
and
if
an
attacker
has
a
10x
advantage.
It's
it's
not
super
useful.
Oh,
that's
like
a
low,
Emacs,
sorry,
a
low,
a
max
yeah.
A
A
A
A
You
could
reconstruct
the
chain
from
the
past,
and
so,
if
you
force
enforce
the
vdf
between
each
block,
then
you
wouldn't
be
able
to
easily
go
back
and
just
recompute
an
entirely
new
chain,
because
you
knew
the
randomness
and
I
think
we
talked
about
this
last
night.
You
had
a
point
about.
If
the
chain
does
influence
the
beacon,
then
that
won't
work,
so
the
beacon,
if
you're,
using
random,
beacon
like
this,
you
need
to
make
sure
there's
some
reseeding
period.
A
A
Yeah
we
just
have
one:
it's
just
one
beacon
somewhere.
You
know
it's
great,
we
could
take.
We
could
put
these
vdf
hardware
on
satellites
in
space
and
just
like
throw
them
out
there
and
they
can
beam
back
random
numbers.
It's
great.
Just
don't
worry
about
it.
What
are
we
doing
here
so
yeah?
That's
that's
what
we're
thinking
and
if
you
have
any
questions,
let
me
know
otherwise.
Let's
talk
later.