foreign
[Music]
So today we're going to talk about
storage proofs I want to introduce this
app
yes
uh 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
given the circumstances
um 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 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 uh 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
uh 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 uh 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 what these are and and so
on
it's so tricky actually I I need to be
multitasking okay so uh 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 uh 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 so
um
it's pretty that's pretty tricky
so about the background that I want you
to have for this Workshop so we're gonna
like start from the biggest Basics so
what is the hashing function just a very
quick reminder I hope it will take less
than a minute uh 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
um yeah finally no not finally uh the
anatomy the ethereum state
it's pretty important to like deal with
this uh 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 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 uh 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
um 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 uh on ethereum is it's
essentially the hash of the header uh
pretty important to deal with this
Primitives and make smart contracts
software so accessing six Oracle State
uh just keep that in mind
let's get to the next part so
um no
ah I think I'm missing one slide
no it's the correct one okay so uh this
is an ethereum block header uh 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
we also have the transactions route
which is pretty useful if you want to
access historical transactions like
their entire body and receive truth so
it's very useful to access any events
logs and and so on and all of these are
like root of the American Patricia tree
America Patricia 3's America 3 just
think of it in that way and most
importantly we have the parent hash and
with the parent hash we can in a way go
go backwards 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 then
we combine these two hashes together
with hash it and do we keep doing that
until we get to essentially one hush and
this is what we call the root mark up
the Trisha three modified Miracle
Patricia 2 to be exactly the data
structure that we use in ethereum
um 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 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 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 uh it's account
based
um 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 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
um
cool 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
so what I want you to like go through
with me today is how we can prove the
ownership of Alliance profile on another
chain
so
a bit of background lens profiles are
represented as nfts and lens is deployed
on polygon I think that's it how do we
get to this 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 uh 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 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 uh 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 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
the first event block
okay A bit of Hands-On so we want to
prove that I own a lens profile on
polygon forever
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 uh structuring 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
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 uh 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 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 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
um 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 how do
we get this storage key
and yeah that's that's it let me check
the time okay
um so
a bit of Hands-On how do we get the
Azure searches it sounds scary and it's
meant to be scary so
we know the slot index the storage index
I want to prove that it's like 0x35
owns with ID 3594
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 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 oh it's much better
and just slot the the storage key is 0x1
so essentially that's the hash that we
got and the result is 0x00
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
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 uh there is
another argument which is
0x1a it's essentially the block number
for which we prove the state
um yeah let's call this method oh by the
way uh 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
okay this is the proof it looks scary it
is scary this entire object is four
kilobytes of data and now I mentioned
before that the state is like a two
level structure first we have a proof
for the account itself and now we have
the proof for the storage I mean for the
actual storage slot
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 uh 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
what's going to be the cost on like an
evm chain that's the cost it's like 600
K of gas that's a lot that kills almost
every single application that you want
to build on top of this nice primitive
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
um but we need to do less hashing 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
um and yeah the verification costs more
or less like 210k gas 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
um 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 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
um 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 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 uh these numbers were
taken from a very nice uh article
written by a16z like a bunch of uh a few
a few months ago
um yeah and I think that's pretty much
it let's get to the next slide so
synchronous cross layer State access so
how can actually a control deployed on
some layer access the state of another
L2 or L1
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 uh 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 so
this is like pretty important and we
sort of can get the commitment from
which we'll recreate the state directly
on on another one and then send it to
another
um 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 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 okay and there are
multiple features to do that all of them
come with some trade-offs and let's go
through all these approaches
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
um 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 uh 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
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 uh okay so
maybe a few a bit of an intro
um 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
um on chain directly so it was almost
impossible to do so
um 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 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
then we have an observer that can
challenge it and then we have finally
the commitment given to a specific chain
in this case start net once everything
is fine
how does it work so we have a set of
trusted three layers validators however
and they attested a specific commitment
is valid so how does it work if you want
to get the commitment AKA The Block hash
of block number
X upon Stark net then instead of sending
a message that will be delayed with a
like slightly delayed we can essentially
make an offshine call just get the
latest one and essentially relay this
message directly to start but it comes
with a few downsides because while we
introduce some trust assumptions uh but
still it's okay okay how does it work so
it works in a way that we have a bunch
of off chain actors who essentially make
this calls and it works more or less
like a multi-seek 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 uh what is uh
actually NPC part doing the MPC part is
very simple it's essentially signing
over like a specific curve some specific
payload and the payload is the
commitment itself and that's it okay so
this is how we actually attest but now
how why this approach is called
optimistic and why it's still secure
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 if you disagree
you just send a message it costs roughly
60 K of gas
and that's it everyone can do that
um
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 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 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
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 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 so essentially the
overhead comes mostly from communication
not computation itself
cool so this is part number one these
are the three approaches obviously I'm
not gonna say which one is the best
because all of them come with some
trade-offs
um 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
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
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 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
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
um
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
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
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 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
um 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 we essentially have access
to any sort of data we want
let's do a recap again so approach
number one answer accumulation on chain
compression option compression three
categories prover overhead gas cost
storage cost
actually gasket should be computational
cost
okay so prover overhead on chain
cumulation do we prove anything well not
really so we are happy answering
compression
well
we still like need to update the miracle
tree I think actually there is uh 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 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
um okay storage cost for the first
approach well seven gigabytes of data it
is horrible so we are very sad
unchain compression
uh 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 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 we can
aggregate multiple sharks together and
so on but obviously there are some
trade-offs especially when it comes to
proving time
um 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 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
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 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 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 latency is still there it's even
bigger because it takes a bit longer in
improving time and verification because
we are super happy because essentially
we can mutualize the cost of verifying
multiple proofs
by just verifying one single Stark proof
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 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 so it must be routed through trainx by
the way I'm
like talking about this in a pretty
abstract Way by Chain X I just miniature
emulator one
um yeah so from chain X I'm just gonna
send again the commitment about change
the as a message and then simply
recreate all these all these headers as
you may not notice it's pretty redundant
because we perform the same computation
on two different chains and we don't
need to do that especially if you use
like the third approach which is
generating the proof on chain but now
there is another problem how do you
actually know what you should do like
you need to be somehow aware of what is
happening and for that reason uh we
introduce an API 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 uh soon
we'll be able to optimize latency wise
um and yeah and essentially
that's it
um just about our API I highly highly
encourage you to check this out
um and yeah like a few final words about
the API it acts as a coordinator 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
um questions
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 uh the specific data inside the
smart contract 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 uh it
can be essentially whatever whatever you
want
oh yeah so uh that's actually a great
question so different chains use a
different like storage uh I would say
architecture they might commit to
America Patricia 3 Miracle 3 uh 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 we go for the for the tree like
through the for the um through the
elements of the proof and then we can
like use a specific hashing function so
for example now Poseidon is Poseidon is
uh is is pretty popular
um 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 you don't really care what
the Strunk is like doing you just just
verify it so that's how we actually did
it deal with it if we need to have it
abstracted we have it abstracted if we
don't then we just don't
foreign
oh yeah
oh yeah that's uh that's actually a good
question because I think I went super
technical uh so actually what we do at
Herodotus every two weeks we have some
internal hackathons and right before the
merge uh 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 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 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
okay I think that's it I have like three
minutes so I guess we can wrap it up and
yeah thanks
[Applause]