►
From YouTube: Herodotus Workshop
Description
Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on IPFS and more.
https://archive.devcon.org/archive/watch/6/herodotus-workshop/index
In this workshop, we will cover how you can leverage the power of Storage Proofs to enable your applications to read the current and historical state of another blockchain in a secure and verifiable manner.
Speaker(s): Marcello Bardus
Track: Developer Infrastructure
Keywords: State expiry,SNARKS,L2s
Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum
Learn more about devcon: https://www.devcon.org/
Learn more about ethereum: https://ethereum.org/
Devcon is the Ethereum conference for developers, researchers, thinkers, and makers.
Devcon 6 was held in Bogotá, Colombia on Oct 11 - 14, 2022.
Devcon is organized and presented by the Ethereum Foundation, with the support of our sponsors. To find out more, please visit https://ethereum.foundation/
A
A
Yes,
I'm
gonna
present
you
storage
proofs
and
explain
why
they're
cool
how
to
work
with
them.
Why
you
need
tooling
to
work
with
them
and
yeah
a
bunch
of
other
things?
Why
is
it
even
possible
all
the
complexities
behind
the
trade-offs
and
so
on?
So
a
few
words
about
storage,
Crews,
well,
I
really
believe
that
they
are
cool,
especially
nowadays.
So
my
thesis
is
that
ethereum
is
pretty
sharded
nowadays
and
with
storage
rules.
We
can
essentially
read
the
state
in
a
almost
synchronous
manner,
which
is
a
pretty
pretty
nice
thing
to
do.
A
Given
the
circumstances
yeah
and
maybe
also,
let
me
explain
why
is
it
even
possible?
So
story
is
essentially
this
idea
that
the
entire
state
is
committed
in
a
cryptographic
manner,
using
some
data
structure
like
Miracle
trees,
Marco
Patricia,
trees
and
so
on
and
yeah.
We
can
essentially
verify
any
specific
piece
of
State
at
any
point
in
time
on
any
domain,
which
is
pretty
nice
and
does
introduce
additional
trust
assumptions.
A
You
just
rely
on
the
security
of
like
the
base
chain,
so
yeah,
that's,
like
storage
proofs
tldr,
where
they're
cool
now
a
bit
of
like
sponsored
section
of
sponsored
section.
So
what
we're
doing
at
harvardus.
So
our
like
goal
is
to
make
smart
contracts
software
in
a
way
by
providing
access
to
historical
state.
A
We
like
I,
said
might
as
this
is
that
ethereum
is
pretty
short
that
nowadays
we
want
to
unchart
it
by
using
storage
Crews,
and
we
want
to
enable
synchronous
data
reads
because
today
we
do
not
have
really
nice
ways
to
make
synchronous
data
access
without
introducing
New,
State
new
trust
assumptions,
so
yeah,
that's
we
do
and
how
we
achieve
that.
We
achieved
it
by
using
obviously
storage
proofs.
We
use
snark,
Starks
and
NPC
I
will
get
why
we
even
use
all
this
tooling,
but
first
a
few
words
about
storage
rules.
A
What
these
are
and
and
so
on.
It's
so
tricky.
Actually
I
I
need
to
be
multitasking,
okay.
So
what
we're
gonna
cover
in
today's
Workshop?
So
all
the
basics
required
to
like
understand
properly
this
primitive,
how
to
like
work
with
it.
How
you
can
generate
these
proofs,
why
they're
pretty
useful
and
how
actually
you
can
access
this
commitments?
I'll
get
later,
what
we
call
the
commitment
in
a
process
manner
and
how
we
make
smart
contracts
software
and
enable
historical
data
reads
cool.
A
A
Just
a
very
quick
reminder:
I
hope
it
will
take
less
than
a
minute
like
generalized
blockchain
Anatomy,
how
I
ethereum
header
looks
like
why
ethereum
they're,
not
like
pretty
on
only
like
ethereum
focused,
however
I
think
that,
for
the
sake
of
this
Workshop,
it's
the
best
to
like
present
on
this
concrete
example,
Miracle
trees,
explain
me
like
on
five
I
will
just
quickly
explain
the
idea,
how
it
works
and
what
is
America
Patricia
tree
without
really
going
too
much
into
digitals
yeah.
Finally,
no,
not.
Finally,
the
anatomy,
the
ethereum
state.
A
It's
pretty
important
to
like
deal
with
this
with
this
primitive
and
finally,
how
to
deal
with
the
storage
layout
cool,
so
touching
function.
Essential.
Is
this
idea,
essentially
it's
this
idea
that
I
can
have
a
function
that
takes
some
input
of
any
size
and
it
always
always
return
an
output
of
a
fixed
size
and
now
what's
also
important.
There
is
no
input,
there
are
no
two
inputs
that
will
generate
the
same
output
and
you
cannot
reverse
the
hashing
function.
A
So
it
means
that,
given
the
output,
we
don't
know
what
is
the
input,
and
this
is
not
what
we
call
like
Collision
resistance,
pretty
useful,
primitive,
like
used
in
blockchains,
I,
will
and
I
think
that's
pretty
much.
It
I
assume
that
everyone
is
like
familiar
with
it
like
yeah,
okay.
Why
is
it
important.
A
So
generalized
blockchain
Anatomy,
so
why
we
call
it
a
chain
because
we
have
a
bunch
of
blocks
mined
together
like
linked
together,
because
each
block
contains
the
reference
the
parent
hash
and
the
previous
header
contains
the
reference
of
the
parent
hash,
which
is
pretty
cool,
and
let
me
remind
what
the
hash,
the
parent
hash
or
the
block
hash
of
on
ethereum
is
it's
essentially
the
hash
of
the
header
pretty
important
to
deal
with
this
Primitives
and
make
smart
contracts
software
so
accessing
six
Oracle
State.
Just
keep
that
in
mind.
A
Let's
get
to
the
next
part,
so
no
I
think
I'm
missing
one
slide.
No,
it's
the
correct
one!
Okay.
So
this
is
an
ethereum
block
header,
as
I
said.
We're
gonna
go
through
the
example
of
ethereum,
concretely,
so
a
bit
of
anatomy
so
to
access
State.
Obviously
we
need
the
state
route.
What
is
the
state
route
is
the
root
of
the
miracle
Patricia
tree
of
the
ethereum
state.
A
I
think!
That's
it.
Let's
get
to
Miracle
tree.
So
essentially
it's
this
idea
that
I
can
take
whatever
amount
of
data
and
I
can
commit
it
in
a
cryptographic
manner
by
using
this
data
structure.
So
on
the
left
side,
we
see
a
standard
Merkle
tree.
So
essentially
all
the
data
goes
to
the
bottom
and
we
essentially
hash
it.
You
know
what
the
hashing
function
is.
A
A
What
you
see
here,
I
hope
you
see
on
the
top.
We
have
the
state
route
and
essentially
the
state
route
is
the
root
of
this
tree
and
now
how
it
works
and
how
you
should
think
of
this
of
this.
It's
a
pretty
complex
data
structure.
I!
Don't
want
you
to
bother
with
it
today,
but
essentially
we
have
three
types
of
like
notes:
we
have
Leaf
nodes,
extension
notes
and
Branch
notes,
so
Leaf
nodes
contain
data.
A
Branch
nodes
contain
data
and
extension
nodes
like
on
the
high
level,
just
help
us
to
like
sort
of
navigate
in
that
tree,
but,
to
be
honest,
to
deal
with
storage
truth,
you
don't
really
need
to
understand
this
part,
but
to
like
build
on
the
low
level
as
we
do.
Obviously,
we
need
to.
We
need
to
do
pretty
pretty
a
lot
with
that
with
that
part,
okay,
so
ethereum
State.
How
is
it
constructed
most
important
takeaway?
A
It's
a
two
level
structure,
so
I
mentioned
that
the
state
route
is
a
commitment
of
the
entire
state,
but
it's
not
really
true,
because
ethereum
is
a
does
it.
Okay
works.
It's
it's
account
based
and
essentially,
the
state
route
is
the
commitment
of
all
the
accounts
that
exist
on
ethereum
and
what
an
account
is
made
of
it's
made
of
a
balance
like
the.
A
If
balance,
it's
announced,
transaction
counter
storage
route,
the
storage
route
is
like
the
root
of
another
America
Patricia
tree,
and
this
America
Patricia
tree
contains
the
key
value
database
that
holds
like
the
mapping
from
storage
key
to
its
actual
value.
And
finally,
we
have
the
code,
it's
essentially
the
hash
of
the
of
the
bytecode
so
main
takeaway.
First,
we
access
accounts,
and
once
we
have
the
account
storage
root,
we
can
access
each
okay
cool.
A
So
to
sum
it
up
like
the
background,
so
main
takeaways,
given
the
block
stay
true
to
you,
can
recreate
any
any
state
for
this
specific
block
on
this
network
and
give
an
initial
trusted
blockage.
You
can
essentially
recreate
all
the
previous
headers,
which
is
pretty
pretty
cool
and
important
to
get
the
ideas
that
I
will
explain
like
pretty
soon
okay.
So,
as
it's
gonna
be
a
workshop,
it's
a
short
one.
So
I
won't
let
you
code,
but
I
will
show
you
some
concrete
examples.
A
A
So,
first
of
all,
the
question
that
we
need
to
answer
to
ourselves
is
how
does
Polygon
commit
to
ethereum
L1,
because
if
we
want
to,
like,
let's
say,
prove
the
ownership
of
a
lens
profile
on
optimize,
we
need
to
know
the
state
route
of
polygon,
but
there
is
material
one
in
the
middle.
So
how
do
we
actually
access
this
on
HTML,
one
primarily
so
polygon
is
a
commitment
commit
commit
chain
and
it
commits
to
to
ethereum
a
bunch
of
things
every
some
amount
of
time
and
essentially
on
L1.
A
We
do
not
validate
the
entire
State
transition,
but
we
just
verify
the
consensus
of
polygon
and
this
checkpoints
how
they
call
it
essentially
contain
State
routes,
and
so
I
mean
not
directly,
but
we
can
access
them
and
let's
get
to
this
to
this
part,
so
this
is
taken
from
polygons
documentation
and
this
is
how
a
checkpoint
looks
like.
So,
as
you
can
see,
the
checkpoint
is
made
of
a
proposal
so
who
proposed
The,
Block,
start
block
and
block.
Give
me
a
second
I'll
get
to
this
and,
most
importantly,
we
have
the
root
question.
A
So
the
root
hush
is
essentially
a
Merkle
tree,
not
America
Patricia
tree
that
contains
all
the
headers
and
which
headers
the
headers
in
the
range
of
start
block
and
and
block
cool.
So
now,
if
we
get
back
to
the
previous
part,
we
can
essentially
prove
with
this
commitment
that
we
know
the
valid
state
route
of
polygon.
A
A
So
number
one
we
go
to
the
contracts,
we
see
a
contract,
we
go
through
it
and
we
see
that.
Essentially,
there
is
a
bunch
of
logic
on
top
of
this
erc721.
This
is
like
the
basic
erc71.
As
you
can
see,
it's
an
abstract
contract
and
it's
slightly
modified
instead
of
having
like
a
standard
mapping
from
like
token
ID
to
its
owner.
We
have
like
token
ID
to
token
data
token
data
is
structuring.
A
This
struct
is
32
bytes
in
total,
20
bytes
is
the
actual
owner
and
the
remaining
12
bytes
represent
when
the
token
was
minted.
Okay,
but
how
do
I
actually
prove
it?
Oh
and
also
very
important
thing
when
dealing
with
storage
layout,
we
have
something
that
is
called
like
slot
indices,
so
each
variable
has
a
given
slot
like
in
the
some
sort
of
meta
layout.
I
call
it
like
that.
It's
probably
the
right
way
anyways
this
mapping.
It
has
like
the
slot
index
too.
I
will
get
to
this
part
in
a
second.
A
Why
it's
two
and
we
have
a
mapping
from
token
ID,
so
you
win
to
32.
Bytes
of
data
represents
represented
as
a
structure,
just
think
of
it
as
some
bytes,
okay,
so
I
guess
most
of
you
use
hard
hot,
so
I'm
gonna
present
on
on
hard
Hut.
There
is
a
very,
very
cool
tool
to
deal
with
storage
layouts.
It's
called
obviously
hard
hot
storage
layout.
This
is
how
you
install
it.
It's
literally
yarn,
install
hardcode,
storage,
layout,
you'll.
Add
one
comment
to
your
Hardware
config.
A
You
write
a
new
script
that
contains
literally
eight
lines
of
code.
You
run
the
script
and
you
get
this
weird
table
and
what
does
it?
What
does
it
really
tell
you
and
oh,
and
by
the
way
why
this
tool
is
pretty
useful?
As
you
see,
this
contract
is
abstract,
so
some
other
contracts
again.
Does
it
still
yeah.
A
Some
countries
can
inherit
from
it
and
obviously,
while
we
inherit
the
storage
layout,
I
mean
this:
does
this
in
synthesis
can
can
get
more
trickier
because
it
also
okay,
so
that's
it's
pretty
hard
to
coordinate
like
one
hand
with
another
hand,
even
though
I'm
Italian,
okay,
anyways
yeah.
We
know
this
slot
in
the
in
the
index
and
that's
how
we
get
it.
We
have
a
column
that
is
called
storage
slot
and,
as
you
see
underscore
token,
data
is
marked
as
two
and
that's
it
okay.
But
what
do
we
do
with
it?
A
A
How
do
we
get
the
storage
key?
We
essentially
do
this
operation,
so
we
concatenate
the
slot.
I
mean
the
key
in
the
mapping
which
is
35.94,
because
this
is
the
token
ID.
As
you
know,
we
have
a
mapping
from
token
ID
to
token
data.
Token
data
contains
the
old
okay,
so
we
concatenate
this
with
the
storage
index.
We
hash
it
all
together.
This
is
the
storage
key
that
we
have,
if
you're
interested
how
to
deal
with
it
for
like
more
complex
mappings
and
like
layouts,
track
the
solidity
documentation.
A
It's
explained
pretty
well,
so
now
that's
to
make
sure
we
got
the
proper
storage
key,
let's
just
check
it.
How
we
can
check
it
super
easy.
Let's
just
make
a
one,
liter
PC
call
to
get
this
storage
at
some
specific
key.
Is
it
if
get
storage
at
so
the
parameters
we
want
to
access?
The
storage
of
what
of
the
lens
Hub
lens
cap
is
a
contract.
That's
essentially
is
the
representation
of
these
profiles
and
its
address
is
0xdd4
and
so
on
and
this
oh,
is
it
better?
A
A
And
we
know
that
it's
32
bytes
of
data,
where
we
have
20
and
12.,
so
let's
split
it
into
12
and
20
bytes
and
what
we
have
is
some
number
like.
You
can
see
0x
a
lot
of
zeros,
then
62
till
d,
and
this
looks
like
a
small
number.
So
apparently
it
is
a
timestamp
and
the
second
part
is
like
35
7
and
it's
literally
our
address.
So
we
got
it
correct.
We
have
the
proper
storage
key
cool.
A
But
how
do
we
actually
get
to
storage
proofs?
So
there
are
standardized
method
in
like
the
Json
or
PC
standard
for
ethereum
appliance,
and
this
method
is
called
eth,
get
proof
which
essentially,
given
the
contract
address
so
I,
better
call.
It
account
address
in
this
specific
case,
allows
us
to
generate
a
state
proof
and
the
last
argument
I
mean
the
sorry.
The
second
argument
is
an
array
that
contains
all
this
Storage
storage
keys
that
we
want
to
prove.
A
There
is
another
argument
which
is
0x1a:
it's
essentially
the
block
number
for
which
we
prove
the
state
yeah.
Let's
call
this
method,
oh
by
the
way
you
might
have
a
question:
how
do
we
deal
with
this
method
on
non-evm
chains
because,
for
example,
on
some
specific
Roll-Ups,
this
method
is
like
not
supported?
Actually,
it's
not
a
big
deal,
because,
if
you
think
of
it,
we
just
need
the
database
and
on
top
of
this
database
we
can
literally
build
this
method.
We
just
need
to
know
how
the
storage
is
constructed.
A
A
It
is
scary,
it's
meant
to
be
scary.
One
proof
is
like
more
or
less
600
bytes
700
bytes.
It
really
depends
like
bigger.
The
storage
is
than
bigger.
The
proof
is,
and
also
more
accounts
we
have
than
bigger.
The
account
proof
is,
so
that's
a
lot
of
cool
data.
If,
if
you
can
imagine
you
can
imagine
and
yeah,
that's
that's
pretty
bad.
Why?
Because
we
need
to
pause
this
proof
on
the
Chain.
So
it's
a
lot
of
cool
data.
But,
okay,
let's,
let's
try.
A
A
So
it's
pretty
bad,
and
why
is
it
that
bad,
so
I
explained
on
the
high
level
what
Merkel
trees
are
America
Patricia
trees
are
on
ethereum,
we
use
Marco,
Patricia
trees,
and
essentially
there
is
a
trade-off
that
when
using
Miracle
Patricia
trees,
the
proof
is
a
slightly
bigger.
It's
like
harder
to
decode
it,
because
actually
we
need
to
do
some
a
bit
of
decoding
there,
but
we
need
to
do
less
hashing.
A
So
this
is
a
trade-off,
but
depending
where
we
actually
verify
this
proof,
it
might
be
more
feasible
to
verify
like
prove
that
is
based
on
Marco
Patricia
trees
or
Miracle
trees.
Okay,
but
there
is
a
solution
and
the
solution
is
what,
if
we
snarkify
such
such
a
proof-
and
we
verify
this
truth
inside
the
snark-
why
is
it
cool?
Because
we
can
like
let's
say
that
I'm
gonna
verify
this
proof
inside
the
graph
crop,
16
circuit
and
yeah,
the
verification
costs
more
or
less
like
210k
gas?
A
The
proof
is
like
way
less
than
600
bytes.
So
it's
good
so
essentially
get
rid
of
the
cold
data,
because
the
proof
itself
can
be
the
private
input
to
the
Circuit
yeah.
We
can
like
use
multiple
proving
system,
depending
on
the
on
the
actual
use
case,
and
now.
Why
is
it
like
very,
very
cool?
So,
first
of
all,
it
removes
call
data
second
model.
A
It
allows
us
to
deal
with
very
UNH
unfriendly
hashing
functions
or
the
evm
these,
the
ones
that
we
don't
have
pre-compiled
for,
like
let's
say
Peterson,
so
it
might
be
like
super
expensive
to
verify
such
a
proof
on
the
evm,
because,
first
of
all,
that's
a
lot
of
cool
data
and
the
hashing
function
is
pretty
like
unfriendly.
But
what
if
we
can
like,
do
it
inside
the
snark
and
just
verify
a
snark
and
yeah
so
another
benefit?
A
This
really
really
helps
in
obstructing
the
way
how
we
verify
this
proofs,
because
you
don't
need
to
have
like
one
generalized
verifier
for
each
type
of
of
proof,
but
you
can
essentially
obstruct
it
behind
behind
the
behind
the
snark,
which
is
which
is
great.
These
numbers
were
taken
from
a
very
nice
article,
written
by
a16z,
like
a
bunch
of
a
few
a
few
months
ago,
yeah
and
I
think
that's
pretty
much
it.
A
So
I
mentioned
that
we
always
need
the
state
route,
but
because
all
of
these
systems
have
a
native
messaging
system,
we
can
send
the
small
commitments
like,
for
example,
the
blockage
to
like
L1.
Usually
it
goes
off-road
one
and
and
yeah
we
can
like
enroll
it
or
send
the
state
through
directly
and
also
we
don't
need
to
rely
on
messaging,
but
we
can,
for
example,
rely
on
the
fact
that
polygon
is
like
a
commit
chain
and
all
these
Roll-Ups
like
commit
from
time
to
time,
they're
like
batches
and
and
so
on.
A
So
if,
let's
say
polygon
commits
another,
one
I
can
send
this
commitment,
then
to
start
I,
don't
start
how
to
do
the
actual
verification
cool.
So
now,
how
do
we
actually
do
that?
So,
let's
break
the
entire
flow
into
like
smallest
pieces,
so
the
flow
is
the
following:
we
need
to
have
access
to
the
commitment
which
is
either
a
block,
hush
or
a
state
route,
and
again
we
can
get
it
or
I
either
by
sending
a
message
relying
on
the
fact
that
is
this
chain
commit.
So
in
a
sense
it's
still
a
message.
A
We
can
relate
in
an
optimistic
manner
or
we
can
go
even
more
crazy
and
verify
the
entire
consensus.
Okay.
So
this
is
Step
number
one.
We
need
to
get
the
commitment
step
number
two:
we
need
to
somehow
access
the
state
route,
so
the
commitments
of
the
state
from
like
a
previous
block
or
the
actual
blog,
because
keep
in
mind
that
these
commitments
are
only
block
hashes
and
we
block
hashes.
We
can
recreate
headers,
but
we
cannot
access
the
state
okay.
So
once
we
have
the
state
route,
we
obviously
need
to
verify
this
state
storage
groups.
A
A
So
approach
number
one
messaging,
so
I
can
send
a
message
from
let's
say:
optimism
to
Eternal
one
I
can
get
the
opco
I
can
get
the
blockers
by
just
calling
the
proper
op
code
and
and
I
get
it
take
some
time,
but
still
I
get
it.
This
is
approach
number
one.
So
we
rely
on
the
built-in
messaging
system,
which
is
I,
think
Fair,
because
the
security
of
it
is
equal
to
the
security
of
the
roll
up
and
if
you're
deploying
an
application
of
this
rollup,
it's
a
fair
assumption
to
do
so.
A
Yeah
it
doesn't.
Oh,
they
don't
know
about
the
downsides,
so
the
message
must
be
delivered.
So
it
introduces
a
significant
delay,
especially
when
dealing
with
the
withdrawal
period
in
the
in
in
the
middle,
and
it
requires
we.
It
requires
interacting
with
multiple
layers.
So,
first
you
need
to
send
a
message
and
then
actually
you
need
to
consume
it.
So
it's
it's
not
ideal,
but
the
trust
assumptions
are
pretty
occasional.
A
Another
approach,
consensus,
validation
by
the
way
this
like
Gremlin,
is
supposed
to
verify
a
bunch
of
PLS
signatures.
I
I
hope
it's
self-explanatory.
Okay,
so
maybe
a
few
a
bit
of
an
intro
right
now
we
have
POS
as
the
native
like
consensus,
algorithm
and
ethereum,
which
is
pretty
great
because
verifying
the
consensus
is
finally
doable
because,
before
like
verifying
the
hashing
function,
eth
hash,
which
was
used
for
proof
of
work,
was
very
memory
intense,
so
not
possible
to
do
inside
the
shark
on
chain
directly.
So
it
was
almost
impossible
to
do
so.
A
So
now
we
also
have
this
fractures
rule
called
lmdigos,
which
is
implementable,
but
doing
all
of
this,
like
directly,
is
pretty
expensive,
so
we
need
to
ideally
wrap
inside
the
snark,
but
there
is
another
downside.
So
a
few
words
about
the
trust
assumptions
you
well,
you
verify
the
consensus
directly.
So
it's
it's
fine.
He
do
you
introduce
any
trust
assumptions,
not
really,
but
the
biggest
downside
that
generating
the
proof
actually
takes
some
time.
A
So,
to
be
honest,
this
approach
is
feasible,
but
comparing
to
messaging
like
quite
often
is
like
almost
the
same,
and
you
pay
a
lot
of
improving
time
and
requires
like
having
more
advanced
infrastructure.
Okay
last
approach
that
we
actually
use
is
something
that
we
call
like
an
optimistic
relator
based
on
NPC
MPC
stands
for
multi-party
computation.
Maybe
before
I
explain
how
it
works.
Let
me
explain
the
the
image
I
hope
it's
self-explanatory,
so
it's
an
NPC
protocol.
We
have
multiple
parties,
it's
multiple
parties
attached
something.
A
A
But
the
reason
why
we
have
NPC
is
because
more
validators
you
have
than
obviously
more
Securities
but
more
validators.
You
have
in
it
like
standard
multi-sig
approach.
You
have
more
signatures
so
more
in
a
way
decentralized.
It
is
then
it's
more
expensive
to
verify,
because
you
need
to
verify
multiple
signatures
and
you
need
to
like
pause
the
signatures.
It's
a
lot
of
cool
data.
Such
approach
is
not
feasible
on
chains.
Oracle
data
is
expensive,
so
at
one
optimistic
rollups
and
yeah
okay.
So
how
does
it
work?
What
is
actually
NPC
part
doing?
A
A
So,
first
of
all,
we
just
posted
some
something
on
the
actual
L2
and,
as
you
may
know,
we
can
send
messages
from
L1
to
L2,
and
such
a
message
can
contain
like
the
proper
commitment.
So
essentially,
even
if
there
are
a
validator
set,
will
lie
that
one
will
never
lie.
So
you
can
just
challenge
such
a
message
and
now
to
participate
in
verifying
this
validators.
It's
super
easy
because
literally
two
RP
sequels
one
call
is
gonna
check
the
actual
commitment
on
the
actual
chain
and
the
other
one
checks
like
what
is
the
claimed
Commitment?
A
If
you
disagree,
you
just
send
a
message:
it
costs
roughly
60
K
of
gas
and
that's
it.
Everyone
can
do
that
and
again,
the
fraud
proving
window
is
pretty
short,
because
it's
essentially
how
long
it
will
take
to
generate
like
the
proof
of
consensus,
if
it's
possible
or
how
long
does
it
take
to
deliver
the
message
and
what
is
pretty
cool
in
this
approach?
It's
not
gas
intensive.
We
verify
just
one
signature.
So
that's
about
this
approach.
Let's
make
a
recap
and
let's
identify
the
trade-offs,
so
we
have
three
approaches.
A
The
first
one
is
messaging.
The
second
one
is
validating
the
consensus
and
the
third
one
is
having
this
optimistic
layer.
So
I
categorize
it
in
four
categories.
The
first
one
is
latency.
The
second
one
is
the
gas
cost.
The
third
one
is
trust
and
the
last
one
is:
what
is
the
off-ching
computation
overhead?
Why
do
I
even
list
it?
Because
if
we
do
some
sort
of
proving,
then
obviously
it
takes
time,
because
we
need
to
generate
the
proof
so
messaging
in
terms
of
latency?
We
are
quite
sad
because
well,
the
message
needs
to
get
delivered.
A
So
once
the
message
gets
delivered
to
some
specific
L2,
L1
will
be
able
to
generate
already
new
block.
So
we
don't
have
like
access
to
the
newest
values
in
terms
of
gas
cost.
It's
not
bad,
but
it's
not
perfect,
because
we
need
to
interact
with
two
chains
at
the
same
time.
So
first
we
need
to
send
a
message
and
consume
it
in
terms
of
trust.
We
are
pretty
happy
because
we
trust
the
rollup
itself
and
it's
a
fair
assumption.
A
Option
computation
overhead
we're
very
happy,
because
there
is
no
computation
to
do
off-chain,
verifying
the
consensus
so
in
terms
of
latency
we
are
outside
because
we
need
to
generate
the
proof
that
we've
done
it.
It
takes
a
bit
of
time
in
terms
of
gas
costs.
We
are
I
would
say
sad
because
we
need
to
verify
the
actual
ZK
proof
which
is
way
more
expensive
than
just
consuming
a
message
or
verifying
a
signature.
In
terms
of
trust.
We
are
happy
because
we
verify
the
consensus
itself
and
computation
overhead.
A
It's
significant
right,
because
we
need
to
generate
the
proof,
Final
Approach,
this
optimistic
layer,
so
in
terms
of
latency
we're
happy,
because
we
simply
make
a
claim
and
we
post
it
on
the
other
chain.
That's
it
gas
cost
we're
very
happy
because
the
well,
we
just
verify
a
signature
in
terms
of
trust.
Well,
we
are
not
that
happy,
but
also
not
that
sad
at
the
same
time,
because
it
still
can
be
challenged
in
an
optimistic
manner
using
a
fraud
proof
computation
option,
computation
overhead
are
pretty
happy
because
we
participate
like
an
NPC
protocol.
A
A
Okay,
accessing
the
headers
I
hope
it's
self-explanatory,
because
we
literally
unroll
something
from
The
Trusted
input
and
The.
Trusted
input
is
again
a
block
hush
for
a
specific
block
X,
and
if
you
follow
the
initial
slides,
that's
essentially
each
block.
We
given
a
blockage,
you
can
recreate
the
block
header
and
knowing
the
block
header,
we
can
access
the
parent
hash
and
by
knowing
the
parent
hash.
You
can
recreate
the
previous
block
header
so
essentially
go
to
the
Genesis
block.
A
So,
given
this
very
small
input,
we
can
essentially
unroll
the
state
or
whatever
was
present
on
the
chain
from
this
block
till
the
Chinese
is
block.
Okay.
So,
as
I
said,
I'm
gonna
explain
everything
on
on
the
example
of
ethereum,
and
today,
all
the
block
headers
together,
are
like
roughly
seven
gigabytes
of
data.
A
So
it's
quite
a
lot
but
okay.
This
is
how
we
actually
do
that
this
is
the
high
level
concept
and
what
are
the
approaches
so
the
first
one
we
call
it
like
on-train
accumulation.
So
essentially
we
do
this
procedure,
this
computation
directly
on
the
Chain,
so
we
provide
all
these
properly
encoded
block
headers
inside
the
call
data
and
the
blockers
that
we
might
receive
as
like
The
Trusted
input
by
sending
a
message
relaying
it
in
optimistic
manner
or
validating
the
consensus
and
yeah
like
recursively,
go
through
all
these
headers
and
and
verify
them.
A
But
there
are
many
many
downsides
because,
first
of
all,
it's
very
cool
data
intensive,
it's
very
computational
intensive
and
now
we
can
store
all
these
headers
on
the
actual
chain.
But
you
know
even
storing
on
an
L2
is
throwing
7.
Gigabytes
of
data.
Is
still
a
significant
cost,
because
the
state
on
an
L2
is
reflected
as
call
data
on
L1,
so
it's
still
expensive
either
way.
But
the
cool
thing
is
that
I
have
direct
access
to
like
State
routes
or
anything
that
I
want
to
access.
A
Next
approach
is
unchain
compression,
so
we
can
still
use
the
same
approaches
previously
so
literally
unroll
it
and
process
this
seven
gigabytes
of
data,
but
instead
of
like
storing,
then
we
can
just
update
the
miracle
tree.
It's
a
nice
approach,
but
comes
again
with
a
few
dump
sites.
It's
very
computationally
intense,
because
if
we
have
like
millions
of
headers,
we
need
to
perform
millions
of
hashes
on
the
Chain.
That's
that's
expensive,
but
at
least
we
we
save
on
on
storing
data
and
also
we
need
to
update
the
miracle
tree,
which
is
which
is
another
cost.
A
Last
downside
is
that
we
need
to
index
all
the
headers
that
have
been
processed.
Why
we
need
to
index
them
because,
if
I
want
to
up
the
access,
a
specific
block,
header
I,
need
to
provide
a
miracle
path,
because,
as
we
update
the
miracle
3-
and
we
just
store
the
root
in
the
contract
itself,
then
I
need
to
know
the
path
right.
So
I
need
to
index
the
data
and
essentially
once
I
it's
the
moment
that
I
want
to
access
that
I
need
to
provide
a
miracle
path.
A
This
approach
is
okay,
it's
I,
wouldn't
say
way
better
than
the
previous
one,
but
it's
way
cheaper
last
approach.
So
there
is
a
very
cool,
primitive
called
Merkel
mountain
ranges,
love
it
and
the
idea
is:
let's
do
the
same-
that
we
do
previously
inside
this
Arc.
So
we
can
provide
this
tremendous
amount
of
data
as
a
private
input
to
the
circuit
and
essentially
do
the
same
computation
like
unrolling
inside
this
record
itself,
and
now
we
have
a
public
input,
which
is
the
blockage,
so
essentially
the
commitment
from
which
we
unroll
it.
A
So
the
trusted
input,
the
public
input-
can
be
literally
asserted
when
we
do
the
on-train
verification
and
why
we
unroll
it.
We
can
accumulate
inside
the
miracle
tree
or
American.
Mountain
range.
Why
American
mountain
range
is
is
cool
because
well,
let's
imagine
that
you
want
to
have
like
seven
gigabytes
of
data
processing.
One
star
like
the
proving
time
is
going
to
be
horrible,
and
why
would
you
even
like
prove
this
commitment
for
like
the
entire
history
like?
Do
you
really
need
that?
A
Probably
not
so,
let's
chunk
it
like
into
smaller
pieces
and
Miracle
mountain
ranges
are
pretty
cool,
primitive
that
allow
to
do
this.
To
do
to
do
this,
to
give
you
like
a
bit
of
intuition,
how
how
does
it
work,
it's
essential,
think
of
it
as
a
tree
of
trees
yeah.
So
once
we
do
all
this
proving
like
of
chain,
we
simply
verify
the
proof
on
chain,
as
you
know,
like
refine.
The
proof
is
way
cheaper
than
doing
this
directly
on
the
chain,
and
still
we
just
provide
a
miracle
path
and
that's
it.
A
A
A
We
still
like
need
to
update
the
miracle
tree.
I
think.
Actually
there
is.
There
is
an
issue
here,
so
I'll
just
skip
this
part
after
in
compression.
We
are
very,
very
sad
because
well,
we
need
to
prove
actually
significant
computation,
so
the
proving
time
is
significant.
Okay,
now,
in
terms
of
gas
cause,
the
third
approach
is
horrible,
because
it
just
costs
a
lot,
because
we
do
the
entire
computation
entry
compression.
A
Well
we're
a
bit
happy
because
we
just
do
a
bit
of
computation,
but
still
it's
a
lot
of
cool
data,
a
lot
of
computation
but
lost
at
least
not
so
much
storage,
storage
cost.
Oh
sorry,
gas
cost
in
the
second
approach,
while
we
just
verify
approved
so
it's
cool,
okay
storage
cost
for
the
first
approach.
Well,
seven
gigabytes
of
data:
it
is
horrible,
so
we
are
very
sad.
A
Unchain
compression,
sorry,
storage
cost
for
unchain
compression.
We
just
the
root
of
the
miracle
tree,
so
we
are
happy
and
in
the
second
case,
we're
even
more
happy
because
we
again,
we
just
essentially
keep
updating
the
tree
and
we
don't
even
need
to
post
a
lot
post
a
lot
of
cool
data,
because
the
call
data
we
passed
is
literally
just
the
proof,
so
we're
very,
very
happy,
but
again
I.
Don't
want
to
say
that
all
of
the
one
of
these
approaches
is
the
best
one,
because,
as
you
see,
there
are
trade-offs
and
yeah.
A
So
this
part
is
actually
pretty
easy.
So,
as
you
know,
as
you
may
notice
here,
I
was
explaining,
like
the
second
step
when
it
comes
to
dealing
with
storage
Crews,
and
now
there
is
the
the
last
part
which
is
essentially
verifying
the
proof
itself.
So
approach
number
one
is
verifying
the
proof
directly
on
the
Chain
approach.
Number
two:
let's
verify
the
proof
inside
the
star
can
then
verify
this
Arc
approach.
Number
three,
let's
verify
multiple
proofs
inside
the
star
can
then
verify
the
snark.
A
We
can
aggregate
multiple
sharks
together
and
so
on,
but
obviously
there
are
some
trade-offs,
especially
when
it
comes
to
proving
time
and
yeah.
So
now
why
the
first
approach
is
feasible
on
on
ZK
rollups,
for
example,
and
start
medical
data
is
very
cheap
and
what
we
want
to
avoid
in
this
specific
processes
called
Data.
So
this
approach
is,
for
example,
visible
on
starknet,
but
for
example,
if
you
want
to
verify
like
a
proof,
an
optimism
or
a
colleague
is
very
expensive.
A
You
want
to
reduce
it
as
much
as
possible,
so
for
that
reason
you
might
want
to
use
a
snark.
And
finally,
if
you
have
like
many
slots
that
you
want
to
prove,
why
can't
you
just
verify
them
inside
one
snark,
you're
gonna
pay
improver
time,
but
you
just
present
one
proof
at
the
end.
So
this
approach
is
cheaper
is
the
cheapest
one,
but
only
if
you
have
multiple
actions
to
to
take
so
there
are
trade-offs.
A
So
let's
identify
them
categories,
approval
overhead,
latency
verification
cost,
so
verifying
the
proof
directly
prove
our
overhead
doesn't
exist.
Latency
doesn't
exist
because
we
don't
need
to
prove
anything
verification
costs.
Well,
it
is
significant
because
we
need
to
possible
data,
we
need
and
we
need
to
do
the
actual
computation
so
like
going
through
the
entire
path
and
each
step
in
the
path
is
one
hashing
function,
oh
and
also,
let
me
get
back
to
the
previous
slide.
I
forgot.
This
is
very
important.
A
Why
wrapping
inside
this
wrapping
inside
this
rank
is
pretty
important
if
you're
like
dealing
with
a
storage
layout
that
is
using
a
specific
hashing
function,
let's
say,
for
example,
Peterson
Peterson
is
not
available
like
on
on
the
EVN
like
you
just
need
to
implement
it's,
not
the
pre-composite,
it's
gonna
be
costly,
but
if
you
do
inside
the
scenario
and
Peterson
is
pretty
smart
friendly,
it's
not
friendly,
then
well,
it
just
verifies
an
arc
on
the
one
and
you
abstract
it.
So
it's
going
to
be
way
way
way
cheaper.
But
again
there
are
trade-offs.
A
Let
me
get
back
to
this.
So
I
went
through
this.
The
normal
competition
3
star
fight
proof
through
overhead.
It
exists.
So
we
are
not
super
happy
latency.
We
are
also
not
happy
because
we
actually
need
to
spend
time
on
improving
this.
This
thing
verification
costs.
We
are
happy
because
well
we
we
just
verify
your
proof.
So
it's
fine
and
snarkifying
multiple
proofs,
the
prover
overhead,
is
still
there.
A
Okay,
went
through
quite
a
lot
of
things,
let's
put
this
all
together,
so,
let's
imagine
we
have
three
chains
and
we
want
to
have
interoperability
interoperability
between
them,
so
we
have
chain
Z,
chain,
X
and
chain
y,
so
it
all
starts
with
a
message:
AKA
commitment.
We
send
a
message
in
order
to
get
the
commitment.
So
let's
say
that
we
send
a
message
from
chain
Z
to
chain
X,
because
on
chain
X
we
want
to
access
the
the
state
of
changing.
A
So
what
do
we
do
once
we
have
the
commitment,
we
literally
recreate
all
the
headers
using
one
of
the
three
approaches,
and
once
we
recreated,
the
header
is
still
the
point
for
which
I
want
to
prove
the
storage.
I,
just
verify
a
proof
and
again
for
verifying
approved.
There
are
multiple
approaches,
but
now,
let's
say
that
on
chain
y
I
want
to
access
the
state
of
change
Z,
and
there
is
no
direct
communication
between
chain
Y
and
chain
Z.
A
A
We
don't
expect,
like
developers
to
deal
with
all
that
complexities,
choosing
the
right
approach
for
the
direct
thing
essentially
right
now,
our
apis
optimizes
cost
wise
soon,
we'll
be
able
to
optimize
latency,
wise
and
yeah,
and
essentially
that's
it
just
about
our
API
I,
highly
highly,
encourage
you
to
check
this
out
and
yeah
like
a
few
final
words
about
the
API.
It
acts
as
a
coordinator.
A
It
optimizes
the
costs,
it
optimizes
the
cost,
because
we
can
batch
multiple
things
and
once
the
job
is
done,
you
get
a
notification
like
via
webhook
VIA,
an
event
like
whatever
you
want
so
essentially
you're.
Not
you
don't
need
to
be
like
an
infrastructure
maintainer
and
you
can
just
focus
on
essentially
building
on
top
of
this
primitive
and
I.
Think
that's
it
questions.
A
So
the
API
essentially
is
a
rest
API.
For
now
we
also
have
a
Json
interface.
We
have
option
function,
entry
points,
so
we
can
request
the
data
like
by
making
enough
jingle
like
calling
a
rest
API
or
like
calling
a
Json
or
PC
method
or,
if
you're,
a
smart
contracts
like
wants
to
access
this
data,
then
you
just
submit
an
event:
we're
gonna
catch
the
event
and
later
on,
like
after
a
bit
of
time,
fit
this
the
specific
data
inside
the
smart
contract.
A
So
we
have
like
a
bunch
of
interfaces
and
by
the
way,
speaking
of
like
the
off-train
entry
points,
once
the
entire
leg
work
is
done
on
our
side,
you
can
get
a
notification,
it
can
be
like
a
web
hook.
We
can
like
send
you
a
bit
of
information
like
using
a
websocket.
It
can
be
essentially
whatever
whatever
you
want.
A
Oh
yeah,
so
that's
actually
a
great
question.
So
different
chains
use
a
different
like
storage,
I
would
say
architecture
they
might
commit
to
America
Patricia
3,
Miracle
3,
maybe
even
vertical
tree
and
obviously
like
I,
start
having
a
generalized
verifier.
It's
like
pretty
it's
not
a
clean
approach,
so
we
essentially
abstract
it,
but
by
using
a
snark
and
inside
the
snark
itself,
we
just
do
the
proper
work.
Like
you
know.
A
We
go
for
the
for
the
tree
like
through
the
for
the
through
the
elements
of
the
proof,
and
then
we
can
like
use
a
specific
hashing
function.
So,
for
example,
now
Poseidon
is
Poseidon
is,
is,
is
pretty
popular,
I
think
that
scroll
uses,
Poseidon
and
also
SDK
sync
uses
Poseidon
on
the
avian
like
performing
Poseidon
will
be
pretty
expensive.
So
for
that
reason
you
cannot
verify
the
proof
directly,
but
what
you
can
do
you
can
do
the
entire
verification
inside
the
snark
and
then
on
the
one.
A
A
A
A
Oh
yeah,
that's
that's
actually
a
good
question
because
I
think
I
went
super
technical,
so
actually
what
we
do
at
Herodotus
every
two
weeks
we
have
some
internal
hackathons
and
right
before
the
merge,
we
built
a
proof
of
concept
that
we
called
merge.
Swap
and
essentially
we
allowed
anyone
to
dump
their
proof
of
work
if
on
proof
of
stake
and
the
way
how
it
works.
A
Would
you
literally
build
a
bridge
on
top
of
this
technology
and
the
bridge
Works
in
a
way
that
you
can
lock
your
if
proof
of
work
inside
a
smart
contract
on
if
proof
of
under,
if
proof
of
work
chain,
you
can
prove
that
you've
done
it
on
ethereum
proof
of
stake.
You
can
once
you
the
proof
is
verified.
You
can
meet
your
C20
token
and
you
can
do
whatever
you
want
with
this
token
and
then,
if
you
want
to
withdraw
back
to,
if
you're
in
proof
of
work,
you
just
burn
it.
A
You
prove
the
fact
that
you
burned
on
the
other
side
and
and
yeah.
That's
it
also
in
terms
of
other
use
cases.
I
think
that
cross-chain
collateralization
is
pretty
cool,
because
this
is
the
place
where
you
want
to
avoid
latency
as
much
as
possible,
and
you
want
to
be
asynchronous
as
much
as
possible
and
essentially
that's
that's
what
we
do
here,
because
our
latency
comes
only
from
from
the
proving
time
but
again
using
some
optimistic
approaches,
and
so
on
there
a
lot
of
things
we
can
do
cure
I,
hope
it
answers
the
question.