Episode 208: Digging into Data Availability with Celestia’s Ismail Khoffi

Transcript

[Music] welcome to xero 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 this week i catch up with ismael coffey 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 git coin 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 xero knowledge podcast and as always i so appreciate these donations but this time around i want to highlight a zk focus 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 ck-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 getcoin 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 zk 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 zk 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's 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's zk money or zk dot money so thank you again aztec now here's my

interview with ismael [Music] so today i'm here with ismael coffey from celestia welcome to the show ismail hello anna thank you pleasure to be here 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 celestia 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 sure i think the first time i actually worked on something related was at epfl in switzerland so like my previous job i was just a humble software engineer at the research institute and i got kind of

bored so i uh joined a lab called this decentralized distributed systems did this and at epfl and we worked on among other things finally about on like uh bitcoin scalability and privacy enhancing technologies so so basically the full like previously i was like a full stack engineer and then i worked on the full stack that is used on any crypto now so cool yeah but it was very academic this was let me think i think it was 2015 maybe 2015 16 okay at least yeah but it was very academic so i was like a research engineer that wasn't doing a phd or something i worked on prototypes that were used then in uh papers like in academic publications

essentially but then you made a you made a leap at some point into i guess web 3 stuff so what what was that transition where did you first jump in so the first real jump into uh like moving away from that academic point of view was a tenement so i joined tenement in ah this whole last year feels like uh like uh the time feels so weird but i think wait i think it was 2018 yeah i'm pretty sure it was 2018 and uh stayed there roughly like one and a half years until shortly after launch of the cosmos hub yeah very cool i've always understood the celestia project as kind of originating in the cosmos ecosystem

and this sort of makes sense uh what like maybe tell me about the origin of celestia or what was lazy ledger previously yeah so actually it originates in more in the ethereum ecosystem i would say yeah because yeah i mean we always perceived as a cosmos only project but that's actually not right i mean we use tenement and we have very like we very much are part of the cosmos ecosystem that's 100 percent true but the idea stems from a research paper that uh vita lake butterine and mustafa albassa my co-founder wrote in like also 2018 about fraud proofs and then they realized yeah some data availability layer is needed and the

the mechanism we use in lazy ledger or slash now celestia is um 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 um yeah and that later led to after after i joined we um explored different consensus engines we looked into like substrate we looked into tenement and um yeah and in the end we ended up with tenement 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

um only cosmos projects because uh you can deploy essentially any execution layer on top of it right interesting so on data availability is a problem that all roll-ups face and all um basically it's a component that is needed in this like modular stack essentially and um it's a cosmos project but not only got it got it it sound and it sounds like like who like your co-founders john is a co-founder and mustafa you just mentioned are there other co-founders um notice there's uh mustafa albassam 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 he's a very technical person nice okay so that's the team and like would you say john and mustafa were they coming more from the ethereum side absolutely yeah i think uh in the beginning we often i often face the challenge that i think tenement is a bit of a paradigm shift in the sense that previously in blockchains you have like all these reorgs 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 that uh now they're very very familiar with cosmos tendermint and all this got it 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 so it won't go a formal definition but uh rather an example i think like state for instance is account balances it's like something

that is everyone can easily understand right like you have account balances and um these account balances are mercalized into a mercury 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 um that is a state transition and then this gets again like the state gets updated and this also updates then the state route 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 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 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 okay you you mentioned validators but i guess miners in a proof of work systems

producers yeah they're just writing the current state onto the blockchain exactly where where is the state transition found though like how do you actually map that so in a block like what is what is it what is a block in the blockchain it usually has a header and um it has block 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 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 right yeah look 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 i want to understand sort of how you're thinking about that so yeah what is the consensus action the consensus action is literally like a bunch of machines reaching consensus on a value and that value here is you can think of it as reaching consensus on the header essentially right like the the what is what is the next block the the

header is the summary of that or the header 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 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 it's confusing and i've 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

so um the data that we're concerned about is the state transitions the transactions in the block i see because light clients if you think of light clients they do not download these let's the whole purpose of 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 or the history of the transactions or the history of the transactions right if we think of of tenement a full node also downloads all

the um consensus messages which are votes essentially a blog 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 i confirmed this is my view and um two of these and then i commit and um to do this to be able to do this they also download all the transactions so they have they have the transactions in their mempool but the block proposer also gossips their view of the block inherent at least their view of the block uh to every other validator so they the full nodes and validators download the header and download the

uh state transitions all of them got it 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 like a node operator a miner a 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 straight state transitions so then i guess the question becomes like why do they need something like celestia if the node providers already have it like why would they need another data availability option 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 downloaded the block like a full node does as you said like they have the history they have on each height of the blockchain they have the whole data in celestia 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 um probabilistic and sampling based so basically how it works is that light lines randomly sample 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 got it but would you use celestia with existing l1s

would you use it with ethereum because like like clients to me within an ecosystem within an like a blockchain if a blockchain also provides a like 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 rollups the sort of like connector chains 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 rollups 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 one and then uses that for the consensus instead but uh you touched on something interesting because you can also use it for other layer one roll-ups for instance we've but we we're talking to several projects that are for instance decay roll-ups how they currently saw data availability is they have a closed committee um that attests to the data essentially although i think it depends on the roll-up but yeah depends on the roll-up maybe yeah there are different solutions to this and but like it's somehow solved off chain for them

um and uh i think the most common approach at least as i know is um to have like a a committee or something that like just attached to the data and celestia could be used as a as a module for them in in the sense that it could be used kind of as a data availability oracle so the celestia valley data set could attest um for like a big zk roll up for instance on ethereum it could attach that their data is actually available on celestia and could put these attestations on chain on ethereum basically a bunch of signatures that has this specific data in in selection we have the concept of a

name space because like the the mercury we use to localize the data think of it as like a domain separated namespace uh mercury and so their specific data would be attested on an ethereum smart contract and then uh clients of that roll up can read these attestations and then they can be sure that the data is actually available for them to recompute the whole chain essentially 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 sort of talk 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 celestia blockchain and from there you could potentially like walk back all of this data and see the state transitions um i mean there's two ways how this could work one is that the like a subnet gives them the data and they additionally have the attestations and they can can verify that this matches and another way is kind of a backup solution where um yeah roll up clients could actually go to celestia and download the data from there that's true yeah both as possible cool 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 setting the stage but okay and i think i'm gonna 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 on cut with the cosmos sdk yes so we we need some state on our layer one as well because it's a proof of stake chain so there's some uh 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 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 so i mean other blockchains all have their own business logic their own execution their own 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 would celestia then be holding kind of the state transitions or this the state or something of a number of different blockchains yes 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 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 that's the business logic of 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 is 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 i see but like you have you have your own validator set and a consensus module you're also writing blocks to a blockchain so yes 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 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 so so first of all the main model how like these other chains would use celestia is i wouldn't call these other chains a layer one um although like i described how zk roll ups that use ethereum could use um 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 one right it uses

the consensus of celestia only and only does execution so roll ups only do execution while celestia does um the consensus and data availability for these roll-ups so so these roll-ups as i said are not necessarily layer ones usually they're not for sure because they don't have their own consensus but we call them like virtual side chains because they are a blockchain without consensus and they produce blocks right and um they dump these blocks for instance onto celestia and um you ask if the different rollups would be like separated on on the on our layer one on celestia so what what celestia does is take the data of

these chains and puts them into a mercury 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 mercury where the data gets merkelized separates them per name space and sorts them by namespace so the end result is still one one short merkle root but each rollup has its own like subtree got it 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 an l1

could potentially use but but here it sounds like the focus is going to be more on roll-ups 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 it's basically just like writing like proofs to the ledger of ethereum and because a theorem is immutable it sort of makes that fixed in time and and immutable as well it's 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 um you could say yes yeah i mean the main difference between how rollups use ethereum and rollups would use celestia is that celestia does not have an execution environment where they can i mean for instance zika rollups 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 but the validity proofs would need to be verified locally because there's no execution environment on on celestia i see um so that's that's the main the only difference between the the two different modes is uncelested there's no

execution in mind while on ethereum there's an execution environment and shrine so to say i see i see and it's sort of like on a theorem you'd have to write the smart contract to do the verification in the case of celestia you are just sort of like you are locking it in but you're not necessarily verifying its correctness 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 rollup and uh that could happen locally for instance 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 agents in the case of polka

dot 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 i'm kind of always thinking of it as like a person or a computer but like yeah what what are they doing so in celestia's case it's much simpler because it's not a two-way bridge you don't have like a client of both chains uh running like celestia is agnostic to all these roll-ups essentially it does not know what the data means that the rollups

give it but the the rollup itself runs a client of 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 off the celestia main chain and follows the the headers and everything and then it takes the rollups 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 uh celestia in the case of just roll-ups and in the case that you mentioned previously where ethereum rollups could use celestia as a

data availability layer there it would be slightly different their additional validators of the celestia main chain would submit attestations to ethereum uh-huh yeah but they would not directly interact with the roll-up okay it's interesting so the roll-up would send something to celestia celestia would say 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 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 this is basically two modes of operation one is the simple case where roll-ups would use celestia directly and then there is this thing where ethereum is in between so to say and that's the thing about 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 walking into celestia using that as its consensus versus uh working with zk rolfs working on ethereum already the floating rollup that has no base chain it has no consensus mechanism it

has a presence yeah it has a consensus mechanism it is the celestia uh consensus okay okay but 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 yeah exactly it's not like there's existing projects that would lock into celestia not yet i mean first we're gonna launch and then they will exist okay okay okay okay got it yeah i mean it is not just theoretical because we are seeing roll-ups on ethereum why wouldn't they exist in the celestia case it's just it's a very similar approach but much cheaper because of gas costs um i i

think i'm i'm very sure that people will play around with this and uh actually deploy high value applications on top of celestia and in the case of these sort of rollups built directly on celestia 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 exactly it's actually it actually even provides stronger security because the like 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 cool but then and going back to that ethereum case with an ethereum based ck roll up you are 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 so so my my understanding is there's two ways to that currently ethereum roll-ups guarantee data availability is one they have these closed committees that are test uh like permission committees that attach to the data availability or the data ends up on ethereum itself which is like super expensive 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 exactly is it a lot cheaper exactly how do you make it cheaper though um you're still writing something to the main chain 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're 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 only here obviously 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 that's a good question so um is that is that still theoretical no i mean um there's is it's not that expensive probably i mean it 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 can you pool together a lot of different roll-ups too yeah 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 on on ethereum uh i mean if the ethereum price continues going up and gas price continue going up then of course i mean uh 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 it'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 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 again 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 proofs 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 it's literally you can think of it as a library with a bunch of modules where you can write

your business logic in go for in yeah yeah mainly in go and um you can do whatever you want so you could like in one exit 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 i see 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 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 uh in the state tree if you wanted to and uh things are heavily underpriced in in the in the cosmos sdk like in terms of there's also a notion of gas um and things are underpriced 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 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 proofs and i'm not sure why i can i can explain why because we um we're currently looking into using uh something else as the default execution environment then the cosmos sdk which is easier to fraud proof so we're eyeballing with the evm essentially and different evm based existing solutions and one that is very tempting is the uh is arbitrary vm essentially because they do not use this like general state fraud proofs but they use what is called an interactive verification game

and um there we know how to do state fraud proofs this is like these this interactive verification game first of all it uses the evm this is more constrained it is very clearly defined it's a very constrained clear execution environment and second the way these fraud proofs work in these detective verification games they're boiled down to a single execution step so like single op code step in in the evm and this sounds much more feasible short term than making the cosmos sdk now frau provable it's still our goal and it's still i think it would be still nice to have uh cosmos sdk chains as rollups

but in the end we will use whatever is more feasible short term and then uh add more and more execution environments so you mentioned substrate and all these yeah we want all these execution environments as rollups on top of celestia as well well we have to start somewhere and we wanted to focus on the cosmos sdk as the default execution environment but we're currently eyeballing more with evm based execution environments as a starting point got it because they're 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 very 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 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 um where the where the the roll-up does the execution so that's i think that's always been the plan and will continue to be the plan but as i said like several like zk roller projects reached out to us or like several rollout projects that build on top of ethereum reached out to us and

are exploring different uh data availability options and celestia is one of those so why we're 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 um 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 this the roll up on top of class stack case because that's potentially much more scalable than the one that uses ethereum midterm i get that 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 not the 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 arbitrarium and not zk sync or something like that like some zk roll up oh those both exist they both have environments that you could lock into celestia why an optimistic i think short term um that these optimistic roll-ups are much more mature already i see in the sense that you can like literally easily deploy everything and then zika 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

wall ups because it's just it just works right fair and the data availability issue of both optimistic roll-ups and ck roll-ups are equal i guess there's it's not that one is more has easier time with data availability okay i mean everyone needs data availability people are like slowly realizing it and uh that's great yeah because you guys have been talking about it for a while yeah yeah mustafa was like way ahead of his time with that 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 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 so that basically would need two things one is that usually currently in the non-modular uh 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 is either validity proofs or like some sort of state fraud proofs which currently the options are interactive verification games or general uh stateful proofs 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 polka dot where relay chain has all the para chains locked into it and the relay chain is the primary source of consensus do you see yourselves as building this like an ecosystem a little bit in that model where multiple sub chains lock into celestia and there develops an ecosystem there in some way yes okay absolutely on the other hand it's potentially much larger than these existing uh solutions because the chain doesn't do execution it's literally not

limited um to for instance i think the relay chain has a limited uh number of execution slots for a reason and this would you would basically have infinite execution slots on on celestia so that's the main difference um so so so yes but potentially it could be much larger [Laughter] ambitious wow i must be chilling a little bit right i mean this is i think that was after the cosmo verse event a few weeks ago i remember having a conversation about celestia and the the way it's sort of evolving into this like

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 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 play 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 uh i would say it's kind of com complementary to each other in the sense that uh shared security on the hub yeah shed 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 how the relay chain and polka dot provides shared security because again um 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 other would need to know exactly what are we validating uh what is this other chain doing they would need to validate the execution as well the state and um that's the main difference they're kind of running the two node system then like the code on the hub and the node on the other chain exactly and in your case you're not so you're like they're running a celestia node within theirs 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 yeah yeah it's also it's also permissionless you can like oh you can just like whatever 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 just like um how i envision it uh i mean it's like very far away currently but like how i envision is like you you press a button uh like you you code your smart contract or you code your business logic then you press a button and you have like a live network that's it i have one this is a question i probably should have asked earlier in the interview but i realized i didn't and that i want to kind of just revisit quickly the like 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 um sure so i mean a light client um in its in its chorus as i said the it just downloads the headers and maybe some state like subset of the state that it cares about in in celestia the uh a light client can additionally do what is called data availability sampling which gives it the guarantee that the full block is there and um is available and um this is like a similar guarantee as if they have downloaded the whole block themselves so where does such a light client live um for instance a rollup sequencer which is like a full node in the roll-up sense could run the

celestial light line do that availability sampling and only post the roll-up blocks onto celestia so basically it 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 on the celestial chain so they could be like you can verify as a like client yourself that the header was actually uh included on the celestia chain by verifying like a microproof

and another option is that the light clients could instead of using the the roll up speed appeal layer they could download the headers directly from the celestia chain and do data availability sampling or or they could like yeah download a subset of the of the data they care about or something yeah interesting yeah that was kind of the second it was the second case that i was curious about was like how those like like lines 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

would you i would like that the the celestia main chain is has hard-coded a few uh ipc connections and i think i mean this is all not set in stone right yet but i would assume that we launch with an ipc connection to the cosmos hub as well as to osmosis and that's it okay but what would that be for would that be for sending celestia tokens there to trade or something or would it be because like there's no need for tokens to come to celestia is there that's true yeah i mean the connection to the hub would be uh that also to us moses are literally just to provide liquidity to like and have have like a have an easy uh

on-boarding experience from atom holders for instance got it got it and and and that would be unidirect like in the in the case that we launched with the ethereum roll-ups uh using celestia then there would be a one directional you need an actual bridge to easier right like that's also it's also a bridge in some sense but you don't need bridges to any of this like these chains that use celestia that's you don't actually need that and then i guess the 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

axle are kind of coming to mind so these types of projects did they need any sort of data availability will they interact with celestia in any way or are these completely like ignoring it's like i might actually be talking about completely different parts of this this network um that's a very good question again i'm not sure if these like bridge providers also first of all this like ecosystem of bridge providers is like exploding and i'm not completely following all of them and it's like there's so many there's axelr 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 totally um i i'm not sure we will they will need

data availability because some of them are their own chains some of i mean they 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 rollups that will exist on top of celestia they could use these bridge providers to connect between these roll-ups yeah between each other yeah i wonder what i guess you would just have a record on celestia that like yeah that happens well that's a very difficult question i guess it depends exactly how the uh

mechanism like 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 boil it down to like uh if you abstract away enough you could think of celestia as a publish subscribe mechanism you 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 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 goth and gas guzzling that it like hurts a little bit but could you ever imagine yourself also acting as a bit of a bridge um i don't think so i mean as in ethereum case as you said you move basically ether to those roll ups lock it in there and move it back 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 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 that defeats the whole purpose so i don't think i don't think they will do that um but maybe this could be a rollup 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 you've worked out some like coexistence with some bridge protocol for the roll-ups that are deployed on

celestia anyway just an idea yeah that could happen or it could be like some some some form of roll-up could act as like a bridging provider itself and the tricky part there is that yeah the composability of rollups depending on how they do fraud proofs will it will take longer for them to have uh what's it called like this this uh you have this like fraud proof window usually it's like a week or something and if you combine these uh and the bridging provider itself would be a roll-up yeah that would be a bit tricky i i think these bridging providers would rather be their own chain or something on ethereum or i don't know yeah be agnostic yeah to me i see them as floating not on ethereum but like kind of floating in

space just connecting a lot of these other networks yeah it makes more sense so probably they will run their own chain yeah 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 yeah i like that a lot because like it like underlines this new paradigm of modular like the modular blockchain stack so i think we're close to the end of the interview we're almost out of time but i 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

so we're currently doing an off-site in berlin the whole team came together to crunch away prs and code and next week we plan to launch a small internal test net 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 uh the first public test net which like we were where we will like also invite other people to participate and then we will launch an incentivized test net and then launch cool are you going to follow the sort of game of stakes model i think so though we didn't think about how to do that

incentivized test net yet and i think it would be nice if there were some like celestia specific challenges in there yeah um but i guess yeah we will we would rather follow that uh game of stakes style incentivized testnet that uh was pioneered in cosmos yeah very cool and and in terms of development so we had like a first mvp where we like uh have a prototype where you can do data availability sampling and we're currently reworking that for the devnet we'll have similar features but instead uh we previously modified a lot of the tenement code and now we use tenement more as a black box and um augment it like the storage and the peer-to-peer

part that is new will add it on top instead of internem indirectly 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 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 two two sessions with two of you to get there but thanks thank you so much as well it's been a pleasure and fun and a big fan of the show thanks so i want to say thank you to the podcast editor henrik the podcast producer tanya and to our listeners

thanks for listening [Music]