Anna Rose (00:05):
Welcome to Zero Knowledge. I'm your host Anna Rose in this podcast, we will be exploring the latest in zero knowledge research and the decentralized web, as well as new paradigms that promise to change the way we interact and transact online.

Anna Rose (00:27):
This week, I catch up with Ismail Khoffi from Celestia, we do a deep dive into the data availability question and learn how Celestia aims to provide a data availability and consensus chain for L2s to use. Before we start in, I just want to highlight the upcoming gitcoin CLR matching round. Starting December 1st. You may have heard me mention these rounds before on the podcast. We do have a grant up for the zero knowledge podcast and as always, I so appreciate these donations. But this time around, I want to highlight a ZK-focused side round that the ZK Validator and other great ZK-focused teams will be contributing to. So this is a side matching round focused on ZK tools and projects. If you're working on open source ZK-focused tech or tools, including learning material or documentation, if you don't have VC funding or a token yet, then you would be eligible for this side round. If you want to get some initial funding directly from the community and from the matching pool, be sure to head, to Gitcoin and create your grant today when choosing the tags for your grant, be sure to choose the option ZK tech and add yourself to our side round. I'm definitely looking forward to learning more about the emerging ZK projects with this experiment with quadratic voting, I've added a link in the show notes to the grants, as well as some info about how the quadratic matching actually works. Also, just as an aside, we are now coming into the last week of the ZH Hack event. It has been so much fun to do this. There's a whole community forming around it. If you haven't already checked it out, please do. And as part of the ZK Hack event, we will be hosting a ZK Job fair. This is happening tomorrow, December 2nd, and this is great for any interested job-seekers or participants in the ZH Hack. Be sure to check it out. If you want to get to know hiring teams and get to know the community a little bit better. I also want to thank this week sponsor Aztec, Aztec aims to be the privacy layer for Ethereum. They believe that unlocking programmable privacy is the next frontier for blockchains. Aztec is the first zero knowledge roll-up built from the ground up for anonymous payments and defy transactions. Recently Aztec hosted a workshop as part of the ZK Hack event, they did a two hour workshop focused on Aztec Connect. So I'll add the link to this in the show notes. If you want to try out the technology that Aztec is building, be sure to head over to zk.money there. You can join thousands of people already sending funds privately on Ethereum that Zk money or zk.money. So thank you again, Aztec. Now here's my interview with Ismail.

Anna Rose (02:56):
So today I'm here with Ismail Khoffi from Celestia welcome to the show Ismail.

Ismail (03:02):
Hello Anna. Thank you. Pleasure to be here.

Anna Rose (03:04):
So last year we actually had John Adler on the show. And in that episode, we chatted about fuel and something called Lazy Ledger, Lazy Ledger, as I understand, has evolved to become Celestia. So we have, we have covered sort of some of the basics about Lazy Ledger and that idea and what Celesia is, but one of the reasons I'm very excited to have you on the show today is I believe that the sort of vision for this data availability module or unit in this ecosystem is becoming so much more relevant today. Like I remember that interview and I remember like, it seemed kind of theoretical and I was like, I didn't really understand why this was so important. And in the last year I've really started to understand that. So yeah, I'm, I'm very much looking forward to digging into this project, but before we do that, why don't we learn a little bit about you? How long have you been in the space? What first got you started?

Ismail (04:04):
Sure. I think the first time I actually worked on something related was at the EPFL in Switzerland. So like my previous job I was just a humble software engineer at a research institute and I got kind of bored. So I joined a lab called decentralized distributed systems datas at EPFL. And we worked on among other things, funnily about unlike Bitcoin scalability and privacy enhancing technologies. So, so basically the full, like previously I would like a full stack engineer and then I worked on the full stack that is used on any crypto now. So yeah, but it was very academic. This was, let me think. I think it was 2015, maybe 2015-16. Yeah. But it was very academic. So it was like a research engineer that wasn't doing a PhD or something. I worked on prototypes that were used then in papers like an academic publications essentially,

Anna Rose (05:04):
But then you made it, you made a leap at some point into, I guess, web3 stuff. So what, what was that transition? Where did you first jump in

Ismail (05:13):
First real jump into like moving away from that academic point of view was a Tendermint. So I joined Tendermint in, this whole last year feels like the time feels so weird, but I think, wait, I think it was 2018. Yeah. I'm pretty sure it was 2018 and stayed there roughly like one and a half years until shortly after launch of the Cosmos Hub.

Anna Rose (05:39):
Yeah. Very cool. I've always understood the Celestia project as kind of originating in the Cosmos ecosystem. And this sort of makes sense. What, like maybe tell me about the origin of Celestia or what was Lazy Ledger previously?

Ismail (05:53):
So actually it originates in more in the Ethereum ecosystem, I would say, yeah, because I mean, we always perceived as a Cosmos only project, but that's actually not right. I mean, we use Tendermint and then we have like, we very much a part of the Cosmos ecosystem, that's a hundred percent true, but the idea stems from a research paper that Vitalik Buterin and Mustafa Al-Bassam, my co-founder wrote in like also 2018 about fraud proofs. And then they realized, yeah, some, some data availability layer is needed. And the, the mechanism we use in Lazy Ledger or slash now Celestia is like the erasure coding and all this is already laid out in that paper. So I would say the original ideas come from like the, how do we scale Ethereum essentially. And yeah. And that later led to after, after I joined, we explore different consensus engines, we looked into like substrate, we looked into Tendermint and yeah, and in the end we ended up with Tendermint and I think that's why we are perceived as like a Cosmos project. But in fact we, I mean, it's like Celestia itself is much larger than just only Cosmos projects because you can deploy essentially any execution layer on top of it. Right. Interesting. So, and data availability is a problem that all roll-ups face and all basically it's, it's a component that is needed in this like modular stack essentially. And it's a Cosmos project, but not only

Anna Rose (07:35):
Got it. Got it. It sounds, it sounds like, like who, like your co-founders John is a co-founder and Mustafa who you just mentioned are there other co-founders?

Ismail (07:44):
No, there's, there's Mustafa Al-Bassam who came up with the idea essentially and John Adler, who I think was like one of the first to write up how roll-ups would work on Ethereum. And that's it, we have Nick White, who is our CEO. I would, he's not officially a founder, but I would definitely count him on that level for sure, he's a very technical person.

Anna Rose (08:09):
Okay. So that's the team and like, would you say John and Mustafa, were they coming more from the Ethereum side?

Ismail (08:15):
Absolutely. Yeah, I think in the beginning we often face the challenge that I think Tendermint is a bit of a paradigm shift in the sense that previously in blockchains you have like all these re-orgs and you don't have immediate finality and all this. And yeah, so, so John and Mustafa certainly come from like either Bitcoin or Ethereum that ecosystems and like that point of view. But now they're very, very familiar with Cosmos Tendermint and all this.

Anna Rose (08:46):
So let's start to dig into the problem that Celestia aims to solve. And that is data availability. I think, to do this, it might be useful to explore kind of like some of the words that are used around this topic, like state, state transition, execution environments versus consensus on a blockchain. So why don't we start with state and state transition? How would you define those two things? How are they different?

Ismail (09:13):
I have a formal definition, but rather than example, I think like state for instance, is account balances is like something that is, everyone can easily understand, right? Like you have account balances and these account balances are merkelised into a merkle tree and that gives you the so-called state route. Right. And state transitions are transactions that modify that state, like for instance, move tokens or coins from one account to the other. So one account balance reduces the other increases and that is a state transition. And then this gets again, like the state gets updated and this also updates then the state route.

Anna Rose (09:57):
Now let's talk a little bit about like, what is the execution environment and what is consensus, right. And maybe does, where does the state transition live and where does the state live?

Ismail (10:09):
Sure. In almost every blockchain, the state lives on chain, essentially by, in the sense that the validators of that chain, they take these state transitions or transactions and apply them, or we say also execute them. And that's what what's like the execution environment for execution means. And in Celestia, essentially, this paradigm shifts a bit in the sense that execution gets outsourced. So to say, like, it gets, it is done in another blockchain essentially.

Anna Rose (10:43):
Okay. You, you mentioned validators, but I guess miners in a proof of work system be doing that. Yeah. They're just writing the current state on to the blockchain, where's the state transition found though? Like how do you actually map that?

Ismail (11:00):
So in a block, like what, what is it, what is a block in the blockchain? It's usually has a header and it has blocked data, right? Which are the actual transactions that then inform the state transitions. And like these transactions live in the block data. And the state is something that the miners block producers, validators, they compute and how it materializes in the block is only in the header in the state route.

Anna Rose (11:30):
Now let's talk a little bit about consensus though. So you, you put state into the execution environment, that's the writing of the block. So this would be like the miners and the validators making decisions on which chain they're following. Right? Yeah. Like I always, I think that distinction needs to be made clear. We've talked about this before on the show, when we talked about ETH2 and they're separating that out, that consensus execution, but I want to understand sort of how you're thinking about that. So yeah. What is the consensus action?

Ismail (11:58):
The consensus action is literally like a bunch of machines reaching consensus on a value. And that value here is you could think of it as reaching consensus on the header essentially, right? Like the, the, what is, what is the next block? The header is a summary of that, or they had a hash. So what consensus gives you is an ordering of, of the chain, right? Like ordering of the blocks essentially, and also of the transactions or the data as well. Right? Like it's an ordering of the blocks. Yeah.

Anna Rose (12:30):
Nice. And so that's a really good distinction now. And the reason I wanted to do a few of these definitions first is the word data availability data could mean lots of things. And so I have definitely been confused in the past about what data availability means. Like, so what, when we talk about the data availability problem, which part of this is, is the data that we're, that we're concerned about or that we don't have.

Ismail (12:57):
So the data that we're concerned about is the state transitions, the transactions in the block because light clients, if you think of light clients, they do not download these. The whole purpose of my light client is that they only follow the headers and only care of like transactions they care about, but not every transaction. That's what full nodes do, right? So the data availability problem is mostly about how can a light client follow these headers, but at the same time cannot be fooled in the sense that you, a block producer cannot hide the transactions from them.

Anna Rose (13:33):
Or the history of the transactions or

Ismail (13:35):
The history of the transactions. Right? If we think of Tendermint, a full node also downloads all the consensus messages, which are votes, essentially a block proposal proposes a summary of the block, essentially. And then there are several rounds which are details of the consensus, but essentially there are signatures of like, Hey, I saw this and I confirmed, this is my view. And two of these and then a commit and to do this, to be able to do this, they also download all the transactions. So they have, have the transactions on the mempool, but the block proposer also gossips their view of the block in Tendermint at least, their view of the block to every other validator. So they, the full nodes and validators download the header and download the state transitions, all of them.

Anna Rose (14:29):
And the reason I said, sort of archival node, I mean, I think in Ethereum, in Cosmos, when we think about a lot of the L1s and like a node operator, a miner, validator, they are actually downloading all of this in just sort of it's happening automatically. They will have the history and they will have all state transitions. So then I guess the question becomes like, why do they need something like, Celestia right. If the node providers already have it, like, why would they need another data availability option?

Ismail (15:02):
Right. I think the difference in Celestia is that you get, for instance, as a light client, you can have the same guarantee as if you don't know that the block like a full node does, as you said, like they have the history to have on each height of the blockchain. They have the whole data in Celestia. Yeah. Do you get the same guarantees as if you do this without doing it, and it's not some magic cryptography, it's a very simple technique and it's probabilistic and sampling based. So basically how it works is that light clients randomly sampled the block. And with each sample, they get a higher assurance that the whole data is available to them to be downloaded without actually downloading it only like a tiny portion of it.

Anna Rose (15:50):
Got it. But what do you use Celestia you with existing L1s? Would you use it with Ethereum? Cause like light clients to me within an ecosystem within an like a blockchain, if a blockchain also provides a light client, they often have a link back to their own full nodes somehow, but so are you for those L1s or are you more for like the L2s, the roll-ups the sort of like connector chains?

Ismail (16:17):
Yeah, that's a very interesting question. I mean, the, the main benefit of focusing on one thing only, and then, which is like data availability makes it that you can use this module for wherever it's needed. And so it can, the main focus that we have is to enable roll-ups and to be like to give these roll-ups the consensus they need, because they don't do consensus themselves like a roll up, just dumps the data or just dumps the block onto a layer 1 and then uses that for the consensus instead. But you touched on something interesting because you can also use it for other layer one roll-ups for instance, we're talking to several projects that are for instance, ZK roll-ups how they currently solve data availability is they have a closed committee that attests to the data, essentially,

Anna Rose (17:12):
Although I think it depends on the roll-up, but yeah.

Ismail (17:13):
But depends on the roll-up maybe yeah, different solutions to this, but like it's somehow solved off chain for them. And I think the most common approach, as least as I know, is to have like a committee or something that like just attests to the data. And Celestia could be used as a, as a module for them in, in, in the sense that it could be used kind of as a data availability Oracle. So the Celestia validator set could attest for like a big ZK roll-up, for instance, on Ethereum. It could attest that their data is actually available on Celestia and could put these attestations on chain, on Ethereum basically a bunch of signatures that attest, this specific data in Celestia - we have the concept of a namespace because like the, the merkle tree we use to merkle-ize the data, think of it as like a domain separated namespace, merkle tree. And so their specific data would be attested on in Ethereum smart contract. And then clients of that roll-up can reduce at the stations. And then they can be sure that the data is actually available for them to recompute the whole chain, essentially.

Anna Rose (18:29):
This sort of gets into, and this is what I think most of the show is going to be about like how, what is Celestia doing that it has access to this stuff? Like you've sort of talked about like you stick the data on Celestia. Yeah. And then Celestia creates a proof on a main chain potentially that that data is correct. But can you, from that proof actually decipher the data or is it more that they'd have to go then to the celestial blockchain? And from there you could potentially like walk back all of this data and see the state transitions.

Ismail (19:02):
I mean, there's two ways how this could work. One is that the, like a sub-net gives them the data and they additionally have the, at the stations and they can, can verify that this matches and another way, is kind of a backup solution where yeah. Roll-up clients could actually go to Celestia and download the data from there. That's true. Yeah. Both is possible.

Anna Rose (19:26):
Oh, cool. Okay. Let's now do a big dive into Celestia itself. I feel like this has been a little bit of my own questions and some preamble setting the stage, but okay. And I think I'm going to actually revisit some of these questions as we go through this. So Celestia is an L1 using Tendermint as a consensus engine, I guess you're built with the Cosmos SDK?

Ismail (19:49):
Yes. So we need some state on our layer 1 as well, because it's a proof of stake chain. So there's some execution happening, but there's a very limited amount limited basically to the proof of stake logic itself. And for that we use the Cosmos SDK. Yeah.

Anna Rose (20:04):
Okay. And so you are like, you are an L1, you're a blockchain in its own. Right. But it's a very specific blockchain with like a very specific purpose. And so I guess this fits into that idea of like many modules focused on different parts kind of rebuilding like a larger computer like structure. So yeah. Tell me exactly what Celestia does? I mean, we've mentioned data availability and stuff like that, but like, I'm trying to picture it in this sea of other modules, how are other blockchains interacting with Celestia?

Ismail (20:36):
So, I mean, other blockchains all have their own business logic, their own execution, their own state machine. So to say, right. And Celestia provides to them essentially the ordering of the blocks of these state machines and the data availability of these state machines as well, like not the data availability of the state machines, but the data availability of the data that then is executed on these state machines

Anna Rose (21:05):
Would Celestia then be holding kind of the state transitions or the, the state or something of a number of different blockchains.

Ismail (21:14):
Yes.

Anna Rose (21:14):
And how, how does that work? Like where does that, is it a storage chain then? Like you know, what, what is actually happening in Celestia? Maybe paint a bit of a picture for us.

Ismail (21:25):
Sure. So, first of all, yes, it would hold the state transitions of these other blockchains. So the transactions, the actual data, it would not hold the state because for like holding the state itself, it would need to understand how to execute these transactions. And Celestia does not do that. That's the

Anna Rose (21:43):
Business logic of

Ismail (21:45):
The business logic of the other blockchain. Exactly. And what Celestia does is it takes the data, orders it and makes sure that the data is available. And it doesn't mean only that it's like downloadable, it's actually dispersed to the network. This is guaranteed by data availability proofs, which are basically the sampling technique that I described before.

Anna Rose (22:07):
But like you have, you have your own validators set and a consensus module. You're also writing blocks to a blockchains. So like, are you, so let's just picture, there's like three other blockchains L1s. Yes. Or maybe like two L1s and a ZK roll-up are using Celestia. Yeah. Are you keeping these in any sort of separate form? Are they just like extra data on this blockchain that the validators are just sort of like consistently writing into these blocks?

Ismail (22:37):
So, so first of all, the main model how like these other chains would use Celestia is I wouldn't call these other chains layer 1. Although like I described how ZK roll-ups that use Ethereum could use Celestia, the main way Celestia will be used though, is that the other chain does not have its own consensus. So that's different from a layer 1, right. It uses the consensus of Celestia only, and only does execution. So roll-ups only do execution while Celestia does the consensus and data availability for these roll-ups. So, so these roll-ups, as I said, not necessarily layer ones, usually they're not for sure that because they don't have their own consensus, but we call them like virtual side chains because they are blockchain without consensus and they produce blocks. Right. And they dump these blocks for instance, onto Celestia. And you ask if the different roll-ups would be like separated on, on the, on our layer 1 on Celestia. So what Celestia does is take the data of these chains and puts them into a merkle tree, which kind of separates and sorts them by their namespace. So every, every application or every chain on top of Celestia has its own namespace and the merkle tree where the data gets merkelised, separates them per namespace and sorts them per namespace. So the end result is still one, one short Merkle root, but each roll-up has its own like sub-tree.

Anna Rose (24:21):
Okay. So now you are really focused more on the roll-up and I, maybe we can explore this a little bit, because earlier on you had sort of said that L1 could potentially use, but, but here it sounds like the focus is going to be more on roll-ups slash side chains that don't have their own consensus in this case is Celestia then just acting as the base chain, like in the Ethereum model with roll-ups you have Ethereum, as it is with all of these, roll-ups kind of using it as the proving, I guess basically just like writing, like proofs to the ledger of Ethereum. And because Ethereum is immutable, it sort of makes that fixed in time and immutable as well, borrowing the security in this case, do you see Celestia as sort of focused on being that borrowed security, but not doing the other stuff that Ethereum does?

Ismail (25:15):
You could say yes. Yeah. I mean, the main difference between how roll-ups use Ethereum and roll-ups would use Celestia yeah. Is that's Celestia does not have an execution environment where they can, I mean, for instance ZK roll-ups would post their validity proofs onto Ethereum and there's like a smart contract that would validate those. Right. And in Celestia, they would just put the data and the validity proofs onto Celestia. Yeah. But the validity proofs would need to be verified locally because there's no execution environment on Celestia. So that's, that's the main, the only difference between the two different modes is on Celestia there's no execution environment while on the Ethereum, there's an execution environment and trying sort of to say.

Anna Rose (25:59):
I see, I see. And it's sort of like on a Ethereum, you'd have to write the smart contract to do the verification in the case of Celestia. Yeah. You are just sort of like, you are locking it in, but you're not necessarily verifying its correctness.

Ismail (26:11):
Yeah. You're locking in the data and the validity proofs, but the verification needs to happen somewhere else, which is again, then outsourced somehow to the roll-up and that could happen locally, for instance.

Anna Rose (26:26):
What is the agent that does that? Like, what is the in-between in between Celestia and these roll-ups like, we've talked a little bit about these kind of connector your agents in the case of Polkadot. You have the collater and I don't know if you'd say this for Cosmos, but you do have like the IBC relayers, you have people who are running bridges, basically these agents, and then there's, there's actually the agent between the ZK roll-up and the Ethereum main chain. So there's an agent running a client on both sides, basically keeping track of it. So what is the agent in Celestia? Yeah, I'm kind of always thinking of it as like a person or a computer, but like what, what are they doing?

Ismail (27:05):
So in Celestia's case is much simpler, because it's not a two way bridge, you don't have like a client of both chains running, like, Celestia is agnostic to all these roll-ups essentially it does not know what the data means that the roll-ups give it, but the roll-up itself runs a client off the Celestia main chain. So of course it could be like a relayer, but I think the base case will just be that the sequencer itself runs a client of the Celestia main chain and follows the headers and everything. And then it takes the roll-ups data and submits a transaction to Celestia, pays for the inclusion of the data. And that's it. Like, there's nothing there's not more going on between that. And Celestia in the case of just roll-ups. In the, in the case that you mentioned previously, where Ethereum roll-ups could use Celestia as a data availability layer, there would be slightly different there. Additionally, validators of to Celestia main chain would submit attestations to Ethereum. But there would not directly interact with the roll-up.

Anna Rose (28:21):
Okay. It's interesting. So the roll-up would send something to Celestia, Celestia would send something to the main chain and would the roll-up ever look at that main chain thing, would it analyze what's been written to the Ethereum main chain?

Ismail (28:35):
Yes. So, so the idea is that the roll-up clients, in the case of Ethereum, the roll up clients would read the attestation and see that a smart contract attested like verified the signatures of the validators of the Celestia chain. Got it. Yeah. It's like two, there's basically two modes of operation. One is the simple case where roll-ups would use Celestia directly and then there's this thing where Ethereum is in between sort of,

Anna Rose (29:04):
And that's the thing about the, the term roll-ups is, I mean, so far very Ethereum focused, but what you're talking about is potentially like non-Ethereum roll-ups just flying in space with no consensus algorithm locking into Celestia using that as its consensus, versus working with ZK roll-ups, working on Ethereum already, the floating roll-up that has no base chain. It has no consensus mechanism.

Ismail (29:31):
Yeah. It has a consensus mechanism. It is the Celestia consensus essentially. Okay.

Anna Rose (29:36):
No, but I'm, I'm more like curious, like who are these projects? Like where, like, what is this more like, theoretically now roll ups could be built on top of Celestia. I mean, it's not like there's existing projects that would lock into Celestia?

Ismail (29:51):
Not yet, I mean, first we gotta launch and then they will exist.

Anna Rose (29:57):
Okay.

Ismail (29:58):
Mean, it is not just theoretical because we are seeing, roll-ups on Ethereum, why wouldn't they exist in this Celestia case? It's just, it's a very similar approach, but much cheaper because of gas costs. I think I'm, I'm very sure that people will play around with this and actually deploy high, high value applications on top of Celestia.

Anna Rose (30:21):
And in the case of these sort of roll-ups built directly on Celestia yet they get the data availability, benefits. They, they have a chance to actually like potentially grab some data from your blockchain that would help them attest to the validity or be able to roll it back, or something like that?

Ismail (30:37):
Exactly. It's actually actually even provide stronger security because the light clients of the roll-up, they do not even need to trust the validator set of the Celestia main chain for attestations, they can verify the data availability locally themselves. So it's like they have a view in their view, the data is available. They don't, they do not need the signature of a validator or like, or two thirds of the validators of Celestia for them. They can do that, but they don't have to, they can just trust them to actually publish the data and then verify it themselves. So it's like, it gives them almost the same or literally very close to the same security guarantees as full nodes without being full nodes.

Anna Rose (31:20):
Cool. But then in going back to that Ethereum case with an Ethereum-based ZK roll-up you're solving a problem that is missing for them right now, they don't have like, as far as I understand the data availability issue of roll-ups you mentioned are currently being fixed. They're being taken care of by these committees or by like sort of these maybe in imperfect.

Ismail (31:42):
So, so my, my understanding is there's two ways to the currently Ethereum roll-ups guarantee data availability is one. They have these closed committees that attest, like permission committees that attest to the data availability or the data ends up on Ethereum itself, which is like super expensive.

Anna Rose (32:01):
What you're offering is like, here's almost like a standardized way of getting data availability for all of these different roll-ups that's a lot cheaper. I'm assuming, is it a lot cheaper? How do you make it cheaper though? You're still writing something to the main chain.

Ismail (32:15):
Why I think it will be a lot, a lot cheaper is mainly because the Celestia main chain is much simpler and focused on that particular use case only you are not competing with the state execution of like potentially hundreds and thousands of smart contracts. It's literally just data availability and nothing else. while on Ethereum you will always compete with the smart contracts that are deployed on Ethereum. Obviously.

Anna Rose (32:41):
But in your case you just talked about this sort of circle, right? Like the, the roll-up posting to Celestia, Celestia, posting to Ethereum. So that post from Celestia to Ethereum, is that going to be expensive?

Ismail (32:53):
That's a good question. So is that,

Anna Rose (32:56):
Is that still theoretical?

Ismail (32:57):
No. I mean there's, it's not that expensive probably depends on how you optimize it, but it won't be that expensive because you can post these attestations, not on every block, for instance.

Anna Rose (33:11):
Can you pool together a lot of different roll-ups too?

Ismail (33:13):
Yeah. Yeah. You can batch, you can batch a bunch of attestations together as well, but I think the main trick is that it is not the data that you post. It is literally just a bunch of signatures, a bunch of signatures and Merkle roots, and that's way cheaper than, than posting the data on Ethereum. I mean, if the Ethereum price continues going up, gas price continue going up then of course, I mean at some point everything will be expensive. Yeah. But I think there's a lot of optimizations you can do for instance, like threshold signatures or yeah. Batching it even more or only posting updates. If the validator set on the Celestia chain changes more than some certain threshold. So there's like a lot of optimizations that can be done, even if the gas costs continue to rise. And I mean, the hope is that also Ethereum will continue to scale to some extent in the foreseeable future that the gas costs will at least to some extent go down as well.

Anna Rose (34:16):
Yeah. Going back to the first example though, where there's actually roll-ups directly locked into Celestia, do you need those to be built with the Cosmos SDK? Do they need to be compatible somehow with Celestia or could it be built with anything? Could it be like substrate-based standalone chains also locking in?

Ismail (34:37):
Very interesting question. So first of all, no, they don't need to be built on the Cosmos SDK. The second point why it's interesting is it's actually very difficult to make the SDK state fraud provable. Okay. I won't go into details how state fraud proof work, but it's just difficult to make these possible in the Cosmos SDK, because the Cosmos SDK is not a very specific, well-defined and constrained execution environment like the EVM, but there's literally, you could think of it as a library with a bunch of modules where you can write your business logic in, Go for instance. Yeah. Mainly in Go. And you can do whatever you want. So you could like in one X, one, one transaction could literally touch all the states that is there that is there and you could it could be very, very expensive. And that makes it very difficult for this one transaction. If there was a fraud proof to make it fraud provable.

Anna Rose (35:36):
When you say fraud proof, you're talking about like the optimistic roll-up style? Yes. Are you saying like, so the optimistic roll-up model where you'd post and then roll back, that's hard to do in the Cosmos SDK?

Ismail (35:43):
It's not the rollback. That's difficult. That's super easy. What is difficult is yeah, because the, because the execution environment is literally you can write any Go code you want and touch every state in the state tree, if you wanted to. And things are heavily under-priced in the, in the Cosmos SDK, like in terms of, there's also a notion of gas and things are under priced. So it's not that it's impossible to do, but it is in its current form, difficult to make it such that a light client can receive a proof and verify that proof by executing literally just one transaction because that one transaction could touch all the state. So that's, that's the difficult part. It's not the rollback that's difficult.

Anna Rose (36:36):
But why are you bringing up fraud-proof in this question? So the question was, this is what I'm confused about. I had asked, like, could you use the Cosmos SDK? And then you mentioned fraud-proof. I'm not sure why

Ismail (36:46):
And explain why, because we we're currently looking into using something else as the default execution environment than the Cosmos SDK, which is easier to fraud-proof. So we eyeballing with the EVM essentially and different EVM-based existing solutions. And one that is very tempting is the is arbitrum's VM essentially, because they do not use this like general state fraud-proofs, but they use what is called an interactive verification game. And there, we know how to do state fraud-pools. This is like this, this interactive verification game. First of all, it's it uses EVM. This is more constrained is very clearly defined. It's a very constrained, clear execution environment. And second, the way these fraud-proofs work, these detective verification games, they're boiled down to a single execution step. So the, our op code step in, in the EVM, and this sounds much more feasible, short term than making the Cosmos SDK now fraud-provable, it's still our goal. And it's still, I think it would be still nice to have a Cosmos SDK chains as roll-ups, but in the end we will use whatever is more feasible short term, and then add more and more execution environments. So you mentioned substrate and all these. Yeah. We want all these execution environments as roll-ups on top of Celestia as well. What we have to start somewhere. And we wanted to focus on the Cosmos SDK as DD for the execution environment, but we currently eyeballing more with EVM based execution environments as a starting point.

Anna Rose (38:32):
Got it. Because of this limitation. But why, like, why care about the optimistic why not just focus on like the ZK roll-up format? Is it because you want variability, you want to give people options to do the optimistic, or is it because you actually see that as being more of like a fitting system that works with Celestia?

Ismail (38:55):
I mean, the original idea was not to use Celestia in combination with Ethereum, but the original idea was that you have this like client-side execution, which is now what we, what we basically call roll-ups where the, where the roll-up does the execution. So that's, I, I think that's always been the plan and will continue to be the plan. But as I said, like several, like ZK roll-up projects reached out to us, or like several roll-up projects that build on top of Ethereum and reached out to us and are exploring different data availability options. And Celestia has one of those. So why are we not focusing solely on this is mainly because yeah, it's one use case for Celestia, and it's not the only use case. And so if, if I had to choose between like one or the other, I would rather try to build only the, the roll-up case, like the roll-up on top of Celestia case, because that's potentially much more scalable than the one that uses Ethereum midterm.

Anna Rose (39:59):
But still like, why you just said, like the original question was, what kind of environment are these sort of side chain roll-ups that would attach to Celestia, Cosmos SDK was your first choice, but now Arbitrum is what you're eyeing is this because they have EVM compatibility already like very figured out? And you'd just like to bring in an EVM style, like extra chain, or the real question I'm asking now is why Arbitrum and not zkSync or something like that. Like some ZK roll-up, those both exist. They both have environments that you could lock into Celestia. Yeah. Why an optimistic?

Ismail (40:36):
I think, short-term that these optimistic roll-ups are much more mature already in the sense that you can like literally easily deploy everything and ZK roll-ups are evolving very, very quickly, but I think it's still, at the current time, it's still better to focus on optimistic roll-ups because it's just, it just works. Right.

Anna Rose (40:59):
And the data availability issue of both optimistic roll-ups and ZK roll-ups are equal, I guess. There's, it's not that one is more, has easier time with data availability? Okay.

Ismail (41:09):
Yeah. I mean, everyone needs data availability. People are like slowly realizing it. And that's great.

Anna Rose (41:16):
Because you guys have been talking about it for awhile.

Ismail (41:18):
Mustafa was like, way ahead of his time.

Anna Rose (41:22):
That's cool. All right. Well, actually, that, this helps a lot. So then I think that also answers the question of like, what kinds of base infrastructure frameworks would be used? And when you say like, you are, maybe eyeing substrate for the future, it's, it's almost like, what would they need to be able to lock into your system? Would they need to be able to do fraud proofs or would they need to be able to do, I don't know, something else before they could do that?

Ismail (41:49):
So basically would need two things. One is that usually currently in the non-modular paradigm execution environments are coupled with the consensus. So you need to decouple those and then replace whatever consensus with just dump the block onto Celestia. And the second thing you need, either validity proofs, or like some sort of state fraud proofs, which currently the options are in verification games, or general state fraud proofs.

Anna Rose (42:20):
Do you feel like, I mean, the Celestia project sounds so much like the Celestia main chain that hub, it does start to have echoes of, I mean, already, we talked about the comparison to Ethereum, but it sounds a little bit like the relay chain as well in Polkadot where relay chain has all the parachains locked into it. And the relay chain is the primary source of consensus. Do you see yourselves as building like an ecosystem a little bit in that model where multiple sub chains lock into Celestia and there develops an ecosystem there?

Ismail (42:55):
In some way? Yes, absolutely. On the other hand, it's potentially much larger than these existing solutions because the chain doesn't do execution. It's literally not limited. To for instance, I think the relay chain has a limited number of execution slots for a reason. And this would be, it would basically have infinite execution slots on Celestia so that's the main difference. So, so, so yes, but potentially it could be much larger... Am I shilling a little bit, right?

Anna Rose (43:36):
I mean, this is, I think that was after the Cosmoverse event a few weeks ago. I remember having a conversation about Celestia and the way it's sort of evolving into this. Like, it, it, it could actually be this very, how do I describe it? Like it could end up touching a lot of different blockchains because of its very focused nature. It's not trying to solve a lot of problems. It's solving one problem very, very well. And if other chains could use that, then they would do it. One, one thought I had though is like in the previous episode, actually the, I think the episode that aired just before this one, I talked with Billy from the ICF and there, they talked about this interchange security. I don't know if you saw that, talk to where they're talking about these like future iterations of what like the Cosmos hub could look like or what a Cosmos zone could look like where they also propose that a little bit, this idea that the consensus lives in this zone, but then these side chains kind of lock in and use the consensus, but do more specific roles themselves. Where do you place Celestia in that conversation? Do you see them as sort of following what you guys have, have laid out? Do you see it as competition? Do you see yourselves as maybe the first example of it?

Ismail (44:52):
I would say it's kind of complimentary to each other in the sense that of shared security on the hub yeah. Shared security on the hub to some extent. I mean, it's like heavily simplified now, but like to some extent is more similar to the harder relay chain and Polkadot provides shared security because again the main difference between Celestia and the hub doing shared security is that the validators of the hub would need to do the execution of the hub. Like would need to know exactly what are we validating? What is this other chain doing? They would need to validate the execution as well, the state. And that's the main difference

Anna Rose (45:32):
Kind of running the two node system then like this out on the hub and the node on the other chain.

Ismail (45:38):
Exactly.

Anna Rose (45:38):
And in your case, you're not, so you're like they're running a Celestia node within there's, I guess it's a very like light node. Probably not super heavy. So it's not like, you know, hard to add to whatever mechanism they already have for execution.

Ismail (45:51):
Yeah, yeah. There's also, it's also permissionless. You can like, oh, you can just like, whenever it's live, you can just go and deploy your roll-up. You don't need any like governance proposals or anything else. Like it's literally this like how I envisioned it I mean it's like very far away currently, but like how I envision it is like you press a button like you, you code your smart contract or you code your business logic, and then you press a button and you have like a live network.

Anna Rose (46:16):
I have one, I, this is a question I probably should've asked earlier in the interview, but I realized I didn't. And that I want to kind of just revisit quickly the light clients where they are and what they're for. Like when we talked about this kind of early on this idea of a light client, not knowing the full state and you were saying that Celestia could actually help with that. Maybe can you paint a picture of like a light client where it lives and how it would actually use Celestia?

Ismail (46:42):
Sure. So I mean a light client in its core, as, as I said, the, it just downloads the headers and maybe some state like subset of the state that that cares about in, in Celestia, a light client can additionally do what is called data availability sampling, which gives it the guarantee that the full block is there and is available. And this is like a similar guarantee as if they have downloaded the whole block themselves. So where does such a light client live? For instance, a roll-up sequencer, which is like a full node in the roll-up sense could run this Celestia light client due to date availability sampling, and only post the roll-up blocks onto Celestia. So basically would run a light client instead of like a Celestia full node. Right. And a light client of the roll-up could either be on the peer to peer layer of the roll-up itself. Like we could think of it as like a sub network having its own peer to peer layer and then following headers. But these headers could be verified on the Celestia chain because the headers are also posted on the Celestia chain. So they could be like, you can verify as a light client yourself that the header was actually included on this Celestia chain by verifying like a merkle proof. And another option is that the light clients could, instead of using the roll-up peer to peer layer, they could download the head directly from the Celestia chain and do data availability, same thing, or they could like, yeah, download a subset of the, of the data they care about or something. Yeah.

Anna Rose (48:20):
Interesting. Yeah, that was kind of the second. It was the second case that I was curious about was like how those like light clients of those subjects, of these roll-ups actually would work. So when we were talking about these like multi-chain universes and, you know, potentially transfers between these different networks, you are built on the Cosmos SDK I I'm assuming you'll have IBC enabled? Maybe not?

Ismail (48:46):
I would like that that the Celestia main chain is, has hard-coded a few IBC connections. And I think, I mean, this is all not set in stone for it yet, but I would assume that we launch with an IBC connection to the Cosmos Hub as well as to Osmosis and thats it.

Anna Rose (49:07):
Okay. But what would that be for? Would that be for sending Celestia tokens there to trade or something? Or would it be, cause like there's no need for tokens to come to Celestia? Is there?

Ismail (49:18):
Yeah. I mean, the connection to the hub would be that also to Osmosis, I'll literally just to provide liquidity, to like, and have, have like a, have an easy onboarding experience from Atom holders, for instance. Got it. Got it. And, and there would be, you need direct, like in the, in the case that we launched with the Ethereum roll-ups using Celestia, then there will be a one directional, uni-directional bridge to Ethereum, right? Like it's also a bridge in some sense.

Anna Rose (49:49):
True, true, true. But you don't need bridges to any of this, like these chains that use Celestia yet that's you don't actually need that? And then I guess the other question is like, let's think more about general purpose bridges, things that are meant to be sort of these connector hubs. They're, they're not IBC. They use often different mechanisms. They might not be in Cosmos. I mean, Optics or Axelar are kind of coming to mind. So these types of projects, did they need any sort of data availability? Will they interact with Celestia anyway? Or are these completely like ignoring if like I might actually be talking about completely different parts of this, this network?

Ismail (50:29):
That's a very good question again, I'm not sure if these like bridge providers and also, first of all, this like ecosystem of bridge providers is like exploding and I'm not completely following all of them. There's like, there's so many there's Axelar. There's like, I don't know. There's like so many like different chains that will launch in the next few months. And there will basically be bridges between other chains. I, I'm not sure we will, they will need data availability because some of them are their own chains. Some of them, I mean, they need data availability as a concept, but if they launch their own consensus networks, they do not inherently need Celestia or like data availability. But I think for us, it could be interesting or not for us, but for that future ecosystem of roll-ups that will exist on top of Celestia. They could use these bridge providers to connect between these roll-ups.

Anna Rose (51:23):
Yeah. Between each other. Yeah. I wonder what the, I guess you would just have a record on Celestia that like it happened.

Ismail (51:32):
Well, that's a very difficult question, I guess it depends exactly how the mechanism like the, it will depend on the mechanism of these like bridge providers. There could be a record of something happened on Celestia. I mean, if you, if you, if you boil it down to like if you abstract away enough, you could think of Celestia as a published subscribed mechanism, you'll publish data and you can subscribe to a particular namespace and get that data. So there's somewhere these bridge providers could benefit from that, for sure. But I cannot foresee how it will look like.

Anna Rose (52:05):
I have like sort of a follow-up to that though. Is do you yourselves ever see yourselves as acting as any sort of bridge? And I know that would like add more complexity. It would change this whole idea of like the single mission, but like, since you would have all of these things locked into you and actually when you think of Ethereum and the roll-ups, that is something that Ethereum somewhat provides already, maybe in a very inefficient way, but you can actually, you can move things from the roll-up to Ethereum. And then from Ethereum to another roll up, do you ever see yourself? I mean, it, it really just even saying that out loud just is so clunky and and gas guzzling that it like hurts a little bit, but could you ever imagine yourself also acting as a bit of a bridge?

Ismail (52:50):
I don't think so. I mean, as in Ethereum's case, as you said, you move basically ether to those, roll-ups lock it in there and move it back

Anna Rose (52:58):
But it's also, if you do trades on those roll-ups, you could move whatever equivalent into Ethereum and then off to another roll-up that's the, like, to me, I see that as like a very clunky bridge in a way.

Ismail (53:10):
So I don't think we will do this because it would require the Celestia main chain to have some sort of execution environment. Right. And then that's the defeats all purpose. So I don't think, I don't think that will do that. But maybe this could be a roll-up.

Anna Rose (53:27):
Or maybe, maybe you partner with a bridge. So there's like the preferred bridge that like already, like, and maybe some of the data is actually like properly articulated within Celestia because it's, you've worked out some like coexistence with some bridge protocol for the roll-ups that are deployed on Celestia. Yeah. Anyway, just an idea

Ismail (53:47):
That could happen or it could be like some, some, some form of roll-up could act as like a bridging provider itself. The tricky part there is that yeah, the composability of roll-ups depending on how they do fraud proofs will, it will take longer for them to have what's it called like this, this you have this like fraud proof window, usually it's like a week or something. And if you combine these are, and the bridging provider itself would be a roll-up. Yeah. That would be a bit tricky. I think these bridging providers would rather be their own chain or something on Ethereum, or I dunno.

Anna Rose (54:21):
Yeah. Be agnostic. Yeah. To me, I see them as floating, not on Ethereum and, but like kind of floating in space, just connecting a lot of these other networks.

Ismail (54:29):
Yeah. It makes more sense. So probably they will run their own chain. Yeah.

Anna Rose (54:32):
Yeah. But they're also doing that single purpose thing. Like it is actually like, you know, just a bridge often. It's not trying to also provide data availability.

Ismail (54:42):
I like that a lot because it's like, it's like underlines this new paradigm of modular, like the modular blockchain stack.

Anna Rose (54:49):
So I think we're close to the end of the interview. We're almost out of time, but I, I want to understand a little bit about like where you're at, where is the project at, you know, you mentioned that there might be in the future, some sort of like connection to Ethereum in the roll-ups, but yeah. Are you live, are you going to be live what's the state?

Ismail (55:09):
So we currently doing an offsite in Berlin. The whole team came together to crunch away PRs and code. And next week we plan to launch a small internal testnet, which we call devnet. And I guess, depending on how this goes three to six months from that, I guess rather three months from that we will launch the first public testnet, which like we will, where we will like also invite other people to participate and then we will launch an incentivized Testnet and then launch.

Anna Rose (55:44):
Cool. Are you going to follow the sort of game of stakes model?

Ismail (55:48):
I think so though, we didn't think about how to do that incentivized Testnet yet. And I think it would be nice if there were some like Celestia specific challenges in there. But I guess, yeah, we will, we would rather follow that game of stakes style incentivized testnet that was pioneered in Cosmos. Yeah. And, and in terms of development. So we had like a first MVP where we like had a prototype where you can do data availability sampling. And we currently reworking that for the devnet we'll have similar features, but instead are, we previously modified a lot of the Tendermint code and now we use Tendermint more as a black box and augmented like the storage and the peer to peer part that is new. We'll add it on top instead of in Tendermint directly.

Anna Rose (56:37):
Cool. Cool. So Ismail, I want to say thank you so much for coming on the show and sharing with us the story of Celestia yet, what it aims to do, where it's at, and also thank you so much for letting me ask you all of these questions about data availability and how this sort of space works. I feel like I now have a much deeper understanding of the project and yes, sorry. It took me to two sessions with two of you to get there, but thanks.

Ismail (57:04):
Thank you so much as well. It's been a pleasure and fun and a big fan of the show.

Anna Rose (57:10):
Thanks. So I want to say thank you to the podcast editor, Henrik, the podcast producer, Tanya, and to our listeners. Thanks for listening.