# Herodotus Workshop

- Channel: [Devcon](https://streameth.org/devcon)
- Date: 2023-10-09
- Duration: 48:10
- Topics: blockchain, smart contracts, distributed ledger, ethereum, Science & Technology
- Watch: https://streameth.org/watch/yt-8mE_0qZNVjo
- YouTube: https://www.youtube.com/watch?v=8mE_0qZNVjo

## 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/

## Transcript

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]