S1E04 [EN] - Kacper&Marcello - Herodotus and Storage Proofs 33:18

Welcome to ABCDE. I'm the host, Yimeng. Hi, I'm Lobai. Hi, everybody's here. We are super excited to have Herodotus to join us, to join our podcast today. So first of all, Kev and Machelo, do you want to say hi to our audience? Sure. Hi, so I'm Casper. I'm one of the co-founders of Herodotus. And

And we're happy here to explain to you guys what our storage proofs, what we've been building for the past few months and what's coming shortly and what we'll be announcing, well releasing soon, which is our latest product called Turbo. Okay, so hey everyone, my name is Marcello, also from Herodotus, one of the co-founders. I'll be probably covering mostly technical things and first of all, thank you, thanks for having me.

Oh, cool. Yeah. First of all, I think you can give some introduction about Herodotus to our audience, because it is quite a new project and many people want to hear about what is proof of storage, etc. So maybe I can take this one. So maybe let's talk about Herodotus first, and then I will talk about storage proofs.

So, first of all, the name comes from a historian. Herodotus was a historian. So I can think here that we provide historical data and what we exactly do is we identified two problems in Ethereum. First of all, Ethereum is getting sharded right now because we see a lot of L2s. And even though it's technically speaking the same network,

smart contracts cannot really talk to each other nicely as they were on the same execution shard. So we want to fix it and basically provide them with synchronous access to state, receipts, and whatever from another shard. And the second part, which is also very relevant, is the fact that smart contracts nowadays are pretty, pretty blind. They cannot see a lot of data that is still on-chain. For example, they cannot access data from even two blocks ago. It's literally impossible.

And this can be fixed by essentially uploading a lot of computation off-chain, because if you think of it, blockchains give you a special tool, which is basically that every block header contains a parent hash, so you can open the parent hash and access historical data. So now let's get into storage proofs.

The way how stateful blockchains such as Ethereum are constructed is that we have a tree and this tree commences the entire state, basically the entire database that is stored by the network participants. So storage for us is

I would say it's an inclusion proof food industry. However, you know, of course to verify it, you need to have a lot of prerequisites. So whenever we talk about storage foods, we mean the bigger picture. So I think it's the definition of a storage food, similar to the definition of a roll-up, is still debatable.

And what we do at Ethereum is essentially try to simplify this whole procedure through easy tooling and try to unify this disjointed Ethereum ecosystem together. Okay. So can you also tell our audience some of your backgrounds and why do you come up with this idea and how come you meet each other and decided to start Euretatus?

So maybe I can start from the technical side. So a few years ago, I was pretty excited about Prolapse. I'm very interested into this topic. But while I was researching how they actually work, I realized that

What I was thinking, Mr. about rollout was not really true, because I thought that there are an extension in Ethereum. In reality, there are parallel blockchains that inherit the security, but they are not an extension because smart contracts don't really have access to the context that normally smart contracting number one would have.

And that kind of made me think of a lot of solutions. So first off, you know, we can send messages, but messages are not that great because first off, they're asynchronous and also they don't scale that well. And then I thought, hmm, but wait a second. Rollups technically give us a lot of computation power and also they give us a lot of bandwidth. So maybe we can use it and access data based on one simple block hash. But then we actually realized that this topic is more interesting and that's how we came up

with this idea of bringing storage proofs on scale to VMs leaving on-chain in order to access both historical data and also data leaving on other shards. Yeah, and if I can maybe add on to that, in this whole procedure we've identified the fact that a lot of the tooling that's necessary to

to really take advantage of storage to build these kind of cross chain solutions is very complex. The barrier of entry is quite high. And if we want to bring these solutions to scale, we came up with the idea of essentially

simplifying this whole procedure as much as possible and trying to spread this narrative through various use cases in different types of market segments. So like governance, gaming, and financial applications.

And we started talking with a lot of projects and identified a lot of trends that first off that new L2s and app specific roll ups are going to become more widely used and popular. A lot of the people we would talk to would highlight the same reoccurring issues. Difficulty with bridges.

such that there are a lot of hacks happen on bridges. There's like community fear towards using a lot of them. And then we identify the fact that in many cases, you can actually separate the fact that you have an asset, but you can separate into having this asset's economic value stored in one spot and having the asset's utility being leveraged elsewhere. And this kind of primitive

Proof to be very, very powerful. Um, and, uh, and we think that in the long term as application specific chains, uh, like kick off and become more widely popular storage proofs will be able to, um,

provide a pathway for further inclusion on those kind of chains. And we have heard of some of the similar concepts like validity proof. And so can you tell us a little bit about the difference between the validity proof and the storage proof? Sure. So maybe I can take this one. So let's start from storage proofs as they are simple.

So like I mentioned before, storage proofs are basically inclusion proof within, in the case of Ethereum, the Merkle-Patricia trial.

that commits to the entire state and the state is nothing else than just a database with a set of key value pairs that say this is a storage slot that has this value or for example this account has this balance, this balance, this storage hash, this code hash and so on. And all of that information is committed to a Merkle-Patricia tree and storage proves as in any Merkle tree like construction

are basically an inclusion proof. So given the root of the string, in the case of here it's called the state root, you can prove that some element within this database is actually committed to the state root. So that's, I would say, the definition of a storage proof, as I mentioned before. In order to perform these verifications, a lot of practices must be met. And that's how we get into validity proofs. So validity proofs, they allow

allow you to prove that some computation has been done correctly without re-executing the computation on the verifier side. This is like a pretty nice property because you can do the heavy lifting option and by heavy lifting, for example, you can open a block hash, prove that you know the preimage, which is a block header, decode the parent hash, prove that you know the preimage to the parent hash, and so on and so on.

even to the genesis block. This is obviously a lot of computation and most importantly it requires a lot of bandwidth. By bandwidth I mean it requires a lot of block headers and this is not something you want to do off-chain. And now validity proofs play very nicely in this case. Why? Because first off the computation can be done off-chain and the verification will happen on-chain and most importantly

the verifier, who's a smart contract country, doesn't need to really see all of these block headers. Why? Because if you think of it, if the--

blockchain of Ethereum nowadays is around 70 million blocks where each block header is one kilobyte. That's a lot of data you'd have to put on chain, but if you use validity proofs, you don't have to. So that's how these two components play nicely together. So just to recap, the main difference is that validity proofs can attest to the validity of some computation, whereas storage proofs are just a name for inclusion proofs within the

commitment scheme in this case the the competition right so if i understand you correctly validity proof is more like it proves from one state to another state of the transmission between these two states has been proved while the storage proofs more like at a particular time the state is like this

It's actually a very good analogy. The validity proofs can prove the transition from one state to the other one, whereas storage proofs can be used to prove the inclusion of some specific element or subset within the bigger set that is the result of the transition.

Right. Then what about the Axiom? You know, Axiom has raised a concept called coprocessor. And when I read that, it's more like a very similar storage proof as well. They want to prove at a particular historical time what account has what kind of balance, et cetera, et cetera. Do you see Axiom as your direct competitors? Like, do you guys share the same concept of that? So we definitely go on concept proof.

Yes, so we do classify ourselves as competitors. However, we do not see ourselves as an equivalent of like a coprocessor. And the reason is such is that we do not intend to offer like complex data feeds, like computation over complex data feeds.

we're more focusing on like being able to access very granular pieces of information between L1s, L2s. And we're putting a lot of emphasis also on this cross chain context. So while we both do go after like historical data as a core component of our businesses, to my understanding, this cross chain element and also our like quite significant focus on StarkNet at this point of time,

does differentiate our approaches quite a bit, but the idea is very similar. Right, I see. Thanks. And also, I'm always very curious and also I think lots of the audience will be curious that why you guys pick up Stackware as your first chain? I mean, why Stalin? Why not anywhere else? And do you have any plans to go multi-chains or other chains after that? That's actually a great question.

Yeah, so one of the most popular questions actually, a little unknown on the fact about is we also do have support for ZK-Singularly on our networks already. However, Starkman has been our home since the very beginning. And the reason behind that is because of cheap computation and call data, which is why we

which was very prominent on on on startnet we've been able to take advantage of that and it's also like a brand new ecosystem that uh had a not not the not the easiest uh barrier eventually so because you had to learn new new programming tools such as cairo um and uh new paradigm and um we thought that like an initial presence in that ecosystem would uh spark the interest of curious developers who wanted to know like how is it possible that you can read data from another origin uh without uh

without this roadblock. I don't know, Martel, maybe you can add something onto this. Yeah. So as Kasper mentioned, StarkNet forced developers to basically learn tools such as Skyro, build new primitive indexers and basically wallets, libraries, and so on and so on. So of course, the lessons that the broader Turing community has learned throughout the years can be already applied to StarkNet from day zero without really...

dragging this technical debt and I think this is great and that leads me to the next reason, maybe to the actual reason, that is this shows and proves that developers on StarCenter are open to new ideas. And they're clearly using storage crews and kind of leaving the boundaries that on-chain VMs put on us that are basically you cannot access the historical state. You're limited only to the current execution shard where in reality it's not really the case, you think.

solutions such as Herodotus. So we thought that the Starfleet ecosystem is a pretty good starting point because we have a huge community that would be eager to experiment with these new ideas. I see. And now you have supported zk-sync as well. Yes, so we have zk-sync earlier currently on our website. Cool.

I was also curious, is there any technical barriers in the future like you guys can support those OP chains like Optimism and Arbitrum instead of the ZK Hero apps? Would there be any technical difficulty doing that? Yes, there will be.

that the chains achieve hard finality in a different way. And the reason for that is because like you can generate a storage proof that something was included for states that has not achieved hard finality yet. And smart contracts should be able to differentiate between proofs that have achieved hard finality and those that have not. We're exploring different ways to tackle this problem.

are not quite there yet as currently we're still focusing on essentially shipping our existing chains to Mainnet which is Starknet and NzkSync. But it is on our roadmap and like in the future we want to be able to support various sorts of like application specific L3s on top of Starknet and on top of other EVM compatible like rollups and etc. Cool. Cool.

And you guys just recently announced a big milestone for the Herodotus Turbo. Can you give a quick intro for what that product is? So maybe I can take this one. So maybe let me talk first about the previous product. So our previous product was also very simple, but not as simple as Turbo. And it was an API.

an API which developers could call offchain saying "Hey, give me a proof for this statement" and that statement can be for example "I am on Stratonet and I want to prove that on Ethereum I had this balance two weeks ago" that can be a statement.

we were generating that proof in the background and then delivering that proof to them and the developer could do whatever he wants with the proof. Verify on-chain, off-chain, basically we don't care. So Turbo is, I would say, an iteration. So we first of all identified that

Calling an API is not hard, but it's not simple enough. Why? Because it requires having API keys, it requires adding some additional logic on the UI side, and the integration is not that easy as it is in the case of Turbo. So now moving on to Turbo. Turbo is basically a set of contracts living on-chain where developers can access any piece of on-chain data in a fully synchronous manner. So imagine that

you can on the left hand side declare for example you win my balance on ethereum one week ago and on the you put the equal sign and on the right side you just invoke the specific turbo contract saying hey read this variable from ethereum so this is like very simple it's usually one line of code

So the end user doesn't have to, the end developer doesn't have to deal with any API keys, credits, and so on and so on. Everything happens fully on-chain. The API is abstracted away. And the best part of it, which I'm pretty excited about, is that we simplified it so much that the end developer is not really required to know what storage truths are. So that's Turbo in a nutshell.

Right. So the previous API is something like the developer has to plug into their app to try to use it. And now you guys, the Turbo is more like a fully, like a D app, which they can just simply use to get what they want and simplify the developer's experience, isn't it? Yeah, basically Turbo is a...

I like to portray Turbo as an interface to the API, aka, it's like behind the scenes what it actually does. We do invoke on our API specific calls, but it's an interface because it's for the first time in the history of Ethereum, you're able to create something like an SQL-like query in one line of code. So in one line of code, you're able to be like select

an item from chain ID one where the block number is, let's say a thousand and the contract account is let's say USDC. And inside there, you wanna pick your accounts balance. In one line of code, you're able to initiate that query without actually having to think about how am I gonna get that proof to the chain? How am I gonna verify it, et cetera? All of this stuff is taken care of behind the scenes.

Right. I see. That's much very clear now. And I guess in that case, it's more like a 2B product, isn't it? Because many are going to be used by the developers, not the users. Correct. Right. Do you have any like existing use case which we can more visionize, like how a developer or 2B product works?

utilize the Turbo to achieve a certain scenarios for whatever cases, like a real use case? Yeah, so on Turbo, it's still being completed, the implementation side. However, we do have several use cases that use the current API implementation. And the most popular one is probably SnapshotX.

Snapshot X allows you to vote on an L2, in this case, StarkNet, based on assets that you hold on L1. And this is very powerful because you're able to reap the utility of your asset without ever having to move it. Normally, if you wanted to take advantage of, like, one of the largest barriers of entry for voting is the fact that you have to interact with the base layer. You have to pay those high transaction fees.

And while you can offload some of voting onto an L2 in order to bridge assets traditionally, well, you would still have to interact with the base layer, move those assets to an L2. And once the assets are there, over time, sure, the cost would go down because you're able to continue voting with them over there. However, when you do that, you have an assumption that the user actually wants to hold their assets there.

And at the end of the day, it's like the safest place to always hold your assets is always going to be on L1. And in many cases, like if let's say you're voting based on something like a very valuable NFT, you might not feel comfortable to bridge it to an alternate chain. So being able to derive utility without actually having to move an asset is one of those powerful characteristics behind storage proof. Cool. Thanks for that.

Maybe I can mention another use case. So it's pragma-oracle. So here we can move on to also L3s. So maybe let me explain pragma in a nutshell. So pragma is an oracle that brings off-chain data to the on-chain world, but with a completely different approach where every

piece of data that is being published is fully transparent. How the transparency is achieved? It's achieved by having a layer 3 dedicated to publishing data. So basically you can see who publishes what information, who's attesting, who's contesting and so on and so on. And everything happens fully on-chain even though the data source is off-chain. And now the problem is that if this L3 is isolated, how the data is going to be consumed?

again and here is where storage foot stepping because thanks to tools such as for example turbo you can deploy a smart contract number one and fully synchronous in a synchronous manner access data from the specific country so you can have very sophisticated off-chain data feeds powered by pragma but pull them to your smart contracts through aerobics i see i see

Can you give us some example that what you're cooperating with Standard to build some applications on Standard? What kind of application are you really hands-on building with the other teams?

Yes. So we have like we're trying to get like there's a very broad application of storage proof. So we're trying to get the use cases in each one of the categories. So we have governance, financial applications. We're exploring integrations with a protocol that's trying to do like cross chain lending.

such that you would be able to take out loans based on assets you hold elsewhere, uh, crossing margin trading such that you could potentially have like volts on, on various different L2s and be able to do, uh, deposits on, on those various L2s. And then you, you would relay storage proofs showcasing that you made a deposit into such a vault.

and are able to trade based on that vault. And in order to secure yourself against a withdrawal from those vaults, the vaults would only allow you to initiate withdrawals if you have a counter storage proof showcasing that you have no outstanding debt obligations on StarkNet. Or you could play around with various approaches such as time locks to ensure that, let's say, if you don't relay an additional storage proof, you would get a margin call.

there's various different ways to tackle this latency that sometimes would exist. There's also gaming. Gaming has been one of the most popular ones that we've been hearing about. And the reasoning for that is that in many cases, let's say if you have a very valuable like in-game NFT, you would not feel comfortable bridging to a brand new application specific chain that just released. And the reasoning for that is it's potentially not audited and it doesn't have...

much traction yet. So in order to counter that, what you could do is these specific chains would be able to allow their users to go to, let's say, a marketplace located elsewhere, purchase their assets elsewhere, and them as the game operators would relay those storage proofs to the application-specific chain. And one of the nice benefits of that is that since you actually don't store any of the economic value,

on your app specific chain, there's really no need to audit it because at the worst case, like the chain would go down and the assets are held elsewhere. As long as they're not locked elsewhere, the user would still be safe.

Yeah, sounds really good. You mentioned that you guys are going to integrate in multi-chain. So what is your vision for multi-chain use case and how will Hereditas be used in some layer 2s and layer 3 and some multi-chain scenarios? Okay, so first off I would like to emphasize that we are primarily focused on Ethereum. So we will bring data

from Ethereum layer one to rollups and also allow rollups to access data from under rollups. And our goal is to eventually connect all Ethereum rollups together because we basically want developers to think of Ethereum as one big data center, one big database, not a sharded

table where you cannot really make joins and that's our mission. So eventually we support every single Ethereum rollup. However, as Kaspar mentioned before, there are also some other things to take into account such as finality on, for example, optimistic rollups. But eventually we support every rollup on Ethereum and also level 3.

And do you have any roadmaps or big milestones coming? And will Heritagist have the next milestone within this year? What is your plan? And what is the big move of next step?

So the biggest next step for us will be deploying to mainnet. We've currently only been on testnets, collecting feedback from users' integrations. And as part of this mainnet integration, we want to, like deployments, we want to be able to showcase Turbo in production. So Turbo, we've been working on it for quite a long time now. We're near completion of it. And we really think that the barrier of entry will be so low that that's

it will be just easy to onboard developers to start using this for their cross-chain needs. And of course, also adding more support for more chains. So the end goal is to essentially have all the major Layer 2s and then those providers that are deploying, let's say, L3s, we have native integrations with those platforms such that users are able to, right from the get-go, be able to read

their data and assets that are located elsewhere. So anything you guys need at this stage? I mean, like, I know for most of the ecosystem, the developers instead of the users is what they want most. What do you think is the best way for the developers to onboarding

to the stock where ecosystem and especially linked to you guys. I mean, I mean, you mentioned that you want the people to build like a multi-chain DeFi or some other project based on use. There are like any, do you, do you reckon there's any requirement for those developers to,

build on top of you guys? Do they have to learn Kero or do they can be using something like Solidity, something easy to build on maybe ZkSync or somewhere else? As mentioned before, we are currently on ZkSync and StratNet, testnets. And we are also going to be eventually on DayOne, other Ethereum rollups and so on. So, Kero, Herodotus and Turbo can be utilized

by writing smart contracts in both Cairo and Solidity. So those developers who are more familiar with Solidity, nothing prevents them to benefit from storage pools and deploy their applications, for example, zkSing or like Kakarot. And on the other hand, those who prefer Cairo because they want to be within that ecosystem and benefit from that community and some of the

properties that StartNet gives, for example, very, very cheap computation, can of course use Turbo on StartNet. And speaking of the barriers of entry, we designed Turbo in such a way that literally the end developer is not required to even know what the storage proof is. So do you guys...

proactively approach all those projects on 2B side or normally is the other way around that those project comes to you guys to get some corporations of using storage proofs? It really varies. Like many times at hackathons we try to kind of like inspire this thinking that you can access from other chains. There's I think a quite wide

like mentality right now with an ecosystem that in order to benefit from something, you actually have to move it. Both its local, like the assets, like physical representation, like the economic value of it and the associated utility. This storage process introduces new paradigm shift where you actually have a separation between those two things.

So from my side, I think I would say recommend to developers to experiment, experiment and experiment. Our APIs are currently live on our website. You can register, get an API key, experiment with the tutorials and stuff we have in our documentation. And if you'd like to have like a one-on-one design session with us, say GM on Discord, follow us on Twitter, shoot us a message and we'll be more than happy to

dive deeper with you on the integrations.

You know, we have been hosting a two-month ZK Hacker Camp, cooperating with Stackware and ZK Sync. And there are a lot of developers, hackers in Asia, and they want to build some interesting stuff on ZK Sync and Startnet. So I think, I guess the last question is, what do you want to talk to these developers in Asia? And do you have any plan

Sure. So we're actively looking to work with projects in Asia. We're going to be also sponsoring Start Korea later this year in September. And we try to onboard projects in various... Ethereum is decentralized. We're an international community, no matter the location. And we have actually as part of Turbo, the docs for this are going to be...

published very soon, we have a program called the Turbo Redistribution Fund, which essentially is intended to incentivize those developers that are deploying with Turbo such that as in the future their contracts are being invoked by users, a portion of the fees associated with those transactions are directed towards the Turbo Redistribution Fund, which in the future

is intended to kind of like be an equivalent of like web two affiliate marketing. So we want to have our users proffer and more details about this program are going to be announced shortly.

Awesome. Yeah, I look forward to seeing more progress and activities in Asia. Yeah, cool. I think that's all our questions. And do you guys have anything that you want to add or you want to say more about your editors? Okay, great. So one thing that I think it's very important to emphasize is that nowadays virtual machines running on

on chains are really, really, really limited. And there is a very good reason for that. The reason being that if every contract was able to access any piece of historical data,

or data from other rollups, so it would imply that every single validator needs to be first of an archive node and also maintain the data from other rollups. So basically be a validator of not only Ethereum, but also every other rollup. So for that reason, this is impossible. However, the usage of validity proofs and storage proofs kind of breaks this ice.

And I think it's really, really exciting what storage truth will generally speaking bring to the innovation landscape of not only Ethereum, like building applications on chain in general. It's going to be pretty, pretty interesting. I think that we're pretty much in an era where databases are being introduced.

Yeah, yeah. Really excited to hear about it. And thank you for showing us the potentials that the storage proof can provide to not only the Ethereum ecosystem, but also the whole Web3. And I think there are going to be more and more interesting applications building on storage proof. Perfect. Thank you for having us. Thank you. Thank you, Casper and Michelle. Thank you. Thank you for coming. Have a nice day. Thanks so much. Bye.