Anna Rose: 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. So today we're here with Ismail and Yaz from Celestia. Welcome to the show. Yaz Khoury: Thank you for having us. Ismail Khoffi: Hey, thanks for having us. Anna Rose: And we have Guillermo as the co-host for this one. Hey, Guillermo. Guillermo Angeris: What's up? Anna Rose: So we're very excited to have you on. We're going to be doing an episode revisiting Celestia. I want to do a quick throwback to a few previous episodes. A long time ago, we had John Adler on the show talking about, I think, Fuel and LazyLedger at the time, which developed into Celestia. Ismail, this is your second time on the show. We did an episode kind of introducing Celestia a little bit more. And then last year I had an episode with Mustafa all about sovereign chains and sort of the sovereign rollup idea. Today we're going to be doing a catch-up on the project. What's really exciting is that the project has since launched. And obviously this is something I really want to cover with the two of you. Quick disclosure before we kick off though. So the ZK Validator is an investor and we're a validator. Also that's a bit of a shout out, we're a validator. Yeah. Guillermo Angeris: Yeah, I guess I also should mention that Bain Capital Crypto is also an investor in Celestia. So, investor warning, what is it called? Investment warning, investment... Anna Rose: This is not investment advice. Guillermo Angeris: There we go, thank you. That's what it is. This is not investment advice. Anna Rose: We're so good at that on this show. And actually, oh, I want to do one other shout out to another video that we did this past summer for the Sovereign Radio. I actually got a chance there to interview you as well. I'll add the links to all of these in the show notes. But I want to welcome you back. And I think for those listeners who are not familiar with those previous episodes or videos, why don't you quickly introduce yourself? Ismail Khoffi: Hey, I'm Ismail Khoffi, and co-founder and CTO of Celestia Labs. Yeah, that's me. Anna Rose: Easy. I guess if anyone wants to hear more of your back story, they can check out the previous episode. Yaz, this is the first time you come on the show. We've actually worked together on a few different projects behind the scenes, but yeah, I'm excited to have you on the show for the first time. Do tell us a little bit about your background. Yaz Khoury: So I'm Yaz Khoury. I'm the head of DevRel at Celestia Labs. Previously, before Celestia, I worked the protocol DevRel at Celo for two years. And before that, I've been at Ethereum Classic, believe it or not. Director of DevRel at Ethereum Classic for a couple of years. And I've done a few things here and there, like with Flashbots, with the EEA, random stints here and there. But yeah, very happy to be here. Anna Rose: Very cool. So I met you, Yaz, when we worked on the Plumo setup ceremony for Celo in 2020, 2021. Guillermo Angeris: Oh, let's go. Anna Rose: Yeah. Yaz Khoury: Yeah, that was really fun, because yeah, I came to you with the idea about what if we live stream across the setup ceremony. And what I remember was, they were doing it on a server, running the computation on a server versus locally. And I decided to do it locally while doing the live stream. And what I didn't realize at the time was when you do these computations, it kind of destroys your Wi-Fi. So while I'm live streaming, my internet was cutting off. Anna Rose: True. Guillermo Angeris: Oh, no. Anna Rose: Yeah, but still a good experiment. I feel like since then, we've also, I mean, so last summer, ZK Validator curated part of the Modular Summit, like, you and I have kind of talked a lot about events, and so it's been fun working with you. So you've just kind of given us a bit of a background on what led you to Celestia. But what do you exactly do today at Celestia? You're saying DevRel, but I feel like your role is kind of broader somehow. Yaz Khoury: So I'm cursed with the experience of things outside of DevRel, because not a lot of people can do them and stuff. So while I'm still doing DevRel stuff, I do a lot of things outside of that. That covers validators, it covers core developers. But yeah, from a high level, the way I structure DevRel at Celestia, there are multiple different teams on DevRel. We have the solution engineering team that I manage. Currently, now we're at four engineers, no, actually five right now on that team. And they tap into all kinds of crazy stuff, right? Like integrations, like the OP Stack or the Arbitrum integration with Celestia. Now we're looking at ZK related kind of work streams. So I manage that team. There's also the developer advocacy kind of... And experience work stream, where we focus a lot on documentation, tutorials, and demo. Then we have programs and that would be like the Modular Summit. Like now we're scoping out soon to be, you know, announced later on a hackathon and all the events and site conferences that we support. And finally, validator relations. So all validators that want to support the network and stuff where we work with them for coordination, network upgrades and hardware coordination and obviously like mainnet launch. And yeah, I mean, we also do a lot of community related operations and the main program there with core developers is what we call the Celestia Improvement Proposal Process or the CIP process. It's kind of like the EIP but it's based on the IETF standards for how do you create working groups when you're building technical specification and implementations. So what I'm trying to say is I barely sleep. Guillermo Angeris: Yes, as the lead cat herder, open source cat herder, I believe, is a possible alternative title. I believe I'm part of this. Yaz Khoury: Cat herding is an art, yeah. Guillermo Angeris: Yeah, yeah. It's an art and a job, apparently, as we found out. Yaz Khoury: It is. Ismail Khoffi: I want to just add to this that we're extremely lucky to have Yaz. Yeah, it's mind-blowing to me how productive he is. Guillermo Angeris: I love it. Anna Rose: Let's define Celestia for folks who aren't familiar with the project. I know that most of this episode is almost going to be teasing out the nuances and talking about updates. But I think it's good to just set the scene. Obviously, Celestia is really well-known. The term DA, or data availability and Celestia are very much intertwined. So how would you define the project today? Ismail Khoffi: Yeah, Celestia is a data availability layer and it's a live peer-to-peer network. So what is a data availability layer? So data availability is often confused with long-term storage or data retrievability, but what it actually means is that in a blockchain, if you publish transactions, how is it guaranteed to the network, to the peer-to-peer network, that these transactions have been made available to the public, like have been published to the network essentially? And data availability network, that's the main purpose of it, like ensuring that everyone can verify that the transactions have been published and they, for a period of time, can be downloaded from the network and can be executed such that you can verify the state of your decentralized application. There's two ways on how these decentralized applications can look like, like very generally speaking. One is through validity proofs. You can, via ZK proofs or cryptographic techniques, ensure that the state transitions that were made are actually valid. And the other approach is optimistic rollups or optimistically via fraud proofs. So you just assume that the state is valid, and in case there has been any malicious state transition, you can prove that via so-called state fraud proofs. And the data availability layer makes that possible. Anna Rose: This is sort of setting the stage with a definition on DA, but how do you define Celestia as a project today? Ismail Khoffi: So Celestia as a project today is the live network and the community around it. It's a broad ecosystem of validators, node operators, and applications building on top. These applications benefit from low costs for data availability. There's a great variety of how these applications can look like. Most of them currently are somehow EVM focused. So they build on OP Stack, for instance, so Optimism Stack, and they settle, for instance, on Arbitrum or Optimism, so Ethereum Layer 2s, but post their data instead of on Ethereum, they post it on Celestia. What we will see more and more, as I said, there's many approaches. What we will see more and more is also alternatives to that, which could be sovereign rollups. Like think of them as their own chains that do not settle on an existing settlement layer, but instead are more like Cosmos zones that do not run their own consensus. Anna Rose: This is interesting to me. So where are the contracts actually deployed for these things? Do they not get deployed at all on Ethereum L1? Yaz Khoury: They do. Anna Rose: They do. Okay. How does something like that work? Yaz Khoury: So the way it would work with an OP Stack implementation is you deploy your OP Stack or Arbitrum-based rollup L2. The smart contracts are still on Ethereum, right? But you're submitting your blobs to Celestia. You're submitting them to Celestia, and what the Celestia validator do through Blobstream is they attest to the data availability through a bridge back to Ethereum. There's a smart contract on Ethereum, like a light client implementation there. And the rollup itself will be sampling via that smart contract. Anna Rose: Okay, interesting. You just mentioned Blobstream. We will have to come back to that, because that's a whole, I don't know if you'd call it product or what exactly it is, but it's a thing in its own right. But yeah, this is super interesting. Guillermo Angeris: I will warn that even the word blob is already delving into jargon territory. So maybe we should also define what that means. I will be the jargon warning person for it to be good. Anna Rose: Oh, good. Be the jargon decoder. I like that. Before we do that, though, before we talk blob, Blobstream, jargon, I actually want to bring us out a little bit. So it sounds like... So, I mean, Celestia is live today. We're already seeing it being used for real. Last time I talked about this on the show was with Mustafa, and then it was very focused on sovereign chains and sort of the vision that he had, it looked a certain way. I wanna talk to you about the launch and then actually what's happened since. So let's first start with the launch. How did it go? Yaz Khoury: As the person, like I coordinated launch in support with Ismail, with the core devs, with the community, with the validators and stuff. The best way I can describe launch, it was like a beautiful symphony, and I would be like the orchestrator. Everyone was performing their musical instruments and I was like, validators, core developers, release the dogs. And it all went perfectly. Like it was actually a very boring launch. And the thing that I missed on launch, I built like a little dashboard to monitor the blocks from... Like there was like a timer until launch and then after that it shows you block production happening. So there was like between block one and block two with like a 20 second block production and I kind of panicked while looking at the dashboard. But the reason for that, like the technical reason for that is because what the core devs told me is the network we're building is topology. So there weren't going to be latency at the validator connected and stuff and start peering with each other. So that was kind of expected but then it went really smoothly. At one point, I think, I was trying to take a photo block 420 but I missed it. But yeah, I did go to Ismail and I was like, I think it went really well. And Ismail was just smiling and just gave me a hug. Ismail Khoffi: True. Guillermo Angeris: I love it. Anna Rose: It was a lovely symphony. I mean, we did a launch party online just a few hours after, and I was surprised at how chill you guys were. You guys were just in a good mood. I mean, we had gone... As a validator, we had seen and gone through some other launches that were definitely more difficult, where something breaks, they have to halt the chain. We've seen some pretty chaotic ones. Did you miss the chaos? Ismail Khoffi: I certainly did not miss the chaos. I was very happy that it went so smoothly. And what Yaz called, it was a boring launch. I think that also means that it was a lot of coordination that happened upfront and a lot of hard work with testnets and basically practicing a lot and making sure the software runs smoothly. I was hoping for a boring launch, and I went as, or it went even more smooth than I would have expected. Guillermo Angeris: How did you guys test this stuff? Like, I remember at some point someone recommended the idea of giving a bunch of like core team developers Raspberry Pi’s and then trying to launch everything simultaneously as a pre-pre-pre-test run. And that'd be like a kind of a CD method where you would distribute... You'd be like, all right, everyone pull, let's start the chain on a bunch of Raspberry Pi sitting in someone's basement in different places in the world. I don't know, how do you even kind of do continual testing on a large decentralized network, actually out of curiosity? This is a very procedural question. Anna Rose: Isn't it an upgrade of a testnet though? Isn't there usually a testnet that they've decided is the one? Ismail Khoffi: Yeah, we didn't do that. That's very often the case. Very often chain launches today are like that where you basically, you launch in more... Almost like in private and it's a testnet essentially and then someone decides like okay this is stable enough and then it's public and then it's mainnet. But what we did was slightly... Not slight, it was very different in the sense that we assembled the Genesis file, we published that and the community agreed on it. There's a date set in the Genesis file, like how it technically works, there's literally just an if statement in the code that says, oh, if it's Genesis time, if it's before Genesis time, just go to sleep. There's an actual line of code that says sleep until Genesis, basically. And then with that moment kicking in, the chain went live. The peers, like the nodes, look for other peers. That's the 20 seconds that Yaz mentioned, then the chain was live. So there was no such period where it was coordinated in the background. It was like more real decentralized launch and as much as possible. Anna Rose: Is this like the OG, this is a bit of the OG way of doing it? Ismail Khoffi: Yeah, I mean, for the Cosmos Hub, we did it very similarly. Anna Rose: Okay. Why did you choose this way, though? Why not do it from a testnet upgrade kind of...? Yaz Khoury: Well, we did have four to five testnet, one of them being the Blockspace Race. The intention of the Blockspace Race was the incentivized testnet program, where we tested so many different things, and there was a lot of, it mixed not only the validators, but also DA nodes, like the light nodes, bridge nodes, and the full nodes. And we had a thousand participants and that allowed us to really, really stress test the first testnet that were designed for mainnet. And that allowed us to update everything after. And then leading up to launch, I was coordinating with some core devs and some people running validators like one testnet a week. And what we're doing was timing it, right? So you have five people participating, each one has a role. Like we had a member from the DevOps team, a member from the Celestia node or the DA team, a member from the core and app team that's running that consensus to client. And then you had me, I don't know what I was doing there, but yeah, I was there. And then you have Ismail, right? And what we did was basically there's several steps that need to happen. Starting with what Ismail was saying, you created the Genesis file. But prior to that, you can create a small Genesis file that has to... Like it doesn't matter what's on it, as long as you specify that it has to start at a specific time in the future. And the future can be like in 30 minutes, right? Like start in 30 minutes, right? And then everyone started running their validator and then we monitor, right? And then block production happened and it kicks off, but then there's a few other things that need to happen. Right? Like the DA node have to make a public release that is compatible with mainnet. Because mainnet launches their consensus client, but then the DA side have to take that, like the first block hash into their software, and then they make a public release. And then you can start your light nodes and store it, full storage node. And what's cool is, when we're timing it, like one week, before mainnet launch, the DevOps team had this whole kind of system in place to time like, making that release for the DA side and deploying bootstrappers, explorers, everything just for testing. So after the first block production for the testnet prior to release, they set things in motion and then they timed it, and I think one of the team members had a stopwatch. And we're like, how long did it take to deploy everything? And they're like, 14 minutes. I'm like, all right, for mainnet launch, maybe you can do it under 10 minutes. They're like, challenge accepted. And it was really fun. Anna Rose: That separation though, the fact that first you have the consensus, then you have this DA step, is that unique to Celestia and like a DA system or do all kind of regular blockchains have that happening under the hood? Yaz Khoury: No, because Celestia, you know, there's multiple layers, right? There's like the consensus and DA layer. But DA has to see what network is it sampling from. So it needs the client to first release on the consensus side before they make a public release for the DA side to start running on DA nodes. Anna Rose: Wow, that's so interesting. Ismail Khoffi: I think technically speaking, it could be the case that if the binaries basically that run the particular networks, right? If they were one binary, I think the Celestia node, basically the light client, and the Celestia node full node, theoretically, they could also do it without that delay initially. I mean, the light clients is a different story because they need some subjective header to initialize, and so some block or some header need to have happened first. But for a full node, theoretically, it could be that they run in parallel and it's not a necessary step, but the way we've implemented is it's more separated. We are thinking of doing our own merge in the sense that to merge these both networks, right? That's something that is considered. I think I'm not sure if there's a CIP for that yet, to be honest, but there's definitely a consideration to make it a bit... Like from the UX also, a bit nicer for node operators to have only one binary, right? And also one peer-to-peer network. But that's just an implementation detail. It doesn't really matter. And I actually kind of like the separation, though I do think it would be nice if there was one peer-to-peer stack used only. The separation itself is like, it's nice that things are so isolated in the sense that if there's a bug in the DA layer, it doesn't trickle down to the consensus layer at all and vice versa. But if the consensus layer breaks down, no blocks are produced, and the DA layer is kind of pointless, but it has its benefits, but I think from the UX perspective for node operators, it would be neat if it was a bit more tightly coupled, just a tiny bit. And I think there's teams working on that. Anna Rose: When you launched, was there any rollups ready to go? Or was it sort of like launch, wait, get rollup deployment? Like I was kind of curious about that. Like if the system sort of like, and the larger picture of it with these rollups kind of branched off it, were there from the start? Or did you actually have to run it a while before they deployed, just to be sure? Ismail Khoffi: They could have deployed immediately. I think maybe out of caution, people didn't in the first week or something, but it's a permissionless system, people could have like with block one started deploying rollups. And it's something that could have happened because on these many testnets that were live, I think they were like, even as mainnet Beta was launched, there were three testnets running in parallel with various deployments. One of them was like Dimension with, I don't know, I think like 10,000 applications running on top. Like a bunch of smaller games and stuff. So it could have been, right? Like it could have been, but most of these rollups were getting ready themselves, most of these rollups had testnets themselves, and I think most of them waited for a few weeks before they started posting blobs or data onto Celestia. Yaz Khoury: The requirement for deploying from testnet to mainnet requires a lot of leg work that's not necessarily technical and stuff, but it does require a lot of kind of management and organization from within those rollup teams, right? So it wasn't like... Yeah, I mean, like Ismail said, it was permissionless. You can immediately deploy if you wish to, but there's a lot of coordination and a lot of things that you gotta do prior to do an official launch, right? Which is why a lot of them existed on testnet because they just wanted to testing. At the same time, it's kind of a good thing nobody launched at the first week. For the first week, we just want to see stable block production. And we just want to monitor the network. We want to see that the DA layer is sampling and all of that stuff. Anna Rose: I feel like this leads us a little bit to the question of Blobstream and kind of introducing what that is. Because on that launch day, we talked about it. But I still don't really know what to call it. I don't know if it's an initiative or a product or rollup itself. I don't know exactly what it is. So you launched a few weeks later or like... Yeah, soon after you had a few rollups happening at this... You know, joining. That, by the way, is very much the picture that Mustafa had kind of described in our interview. Like that sovereign chains and that sort of model. But then, yeah, let's talk about Blobstream because I feel like that kind of changes that picture a little bit, at least for me. And maybe I don't understand it right, but yeah, what is Blobstream? Let's start there. And tell me if it is a rollup, is it a product, is it an initiative? Ismail Khoffi: It's not a rollup. It's a kind of philosophical question. If it's a product, I would say yes. Guillermo Angeris: Let's define the type of the object, I think, is what Anna's kind of... Anna Rose: Is it a movement? Ismail Khoffi: It's also kind of an initiative in the sense that someone needs to deploy a smart contract for it to work on Ethereum and validators need to start running what is called a relayer or orchestrator that actually posts data attestations to Ethereum to that smart contract to digest. So it's not a rollup. Anna Rose: Okay, that's clear. Ismail Khoffi: So what you could think of... Like from a very high level perspective, what you could think of or a good analogy is like a one-way bridge from Celestia to Ethereum, and the only purpose of that bridge is to relay attestations, basically signatures of the validators to Ethereum that they attach to this data, this data route was published to the network. That's a very simple primitive, and for that, you need like these smart contracts to digest these attestations. And then the purpose of it is that applications deployed on Ethereum can then, like layer 2s, layer 3s on Ethereum, can then post their data onto Celestia and get an attestation back on Ethereum that this data was published on Celestia. And then they can use Ethereum or a layer above Ethereum for its, like Arbitrum directly or Optimism or any layer 2 on top of Ethereum, can use that for settlements. So they have that for bridging, for state fraud proofs or for validity proofs, they can use their settlement layer as before, either that's Ethereum or layer 2 on top of Ethereum, but they can now post their data instead of posting it on Ethereum, which is expensive, or on the regular settlement layer, which could still be more expensive, they can now post the data on Celestia directly instead of like into call data in to the dedicated EVM, either the layer 1 or layer 2. Anna Rose: I want to break this down into these pieces if I can. So in this case, the Ethereum L1 is the consensus. It's the smart contract platform where the smart contract is deployed, right? Yaz Khoury: It's just settlement. Anna Rose: I thought the L2 was settlement. Yaz Khoury: No, the L2 is execution. Guillermo Angeris: It can be execution. Anna Rose: I want to understand. Help me with this. Where is the consensus, where's the settlement, where's the DA happening? That's like the kind of... Because I feel like they're being split, right? Yaz Khoury: Yeah. The DA and the consensus is on Celestia. Anna Rose: Oh, I see. Okay. Yaz Khoury: The settlement is on Ethereum and the execution is on that layer 2. Anna Rose: Oh, wow. Okay. So this goes back, by the way, to that original example you gave with the OP Stack, because you had said L2 for settlement, but you're saying like the execution of the settlement happens on the L2. But the L1 is the settlement layer still. I didn't realize that consensus and DA go over to Celestia. Ismail Khoffi: I have to add one more thing. It's consensus and DA only for the data of that application or chain. It is not for the state. Anna Rose: Yeah, so the consensus for the state remains on Ethereum. Yaz Khoury: Yeah. Ismail Khoffi: On Ethereum or on the settlement layer that application uses to be more general. Anna Rose: Wow, this is where it's so fascinating, like these parts that we've understood. So I've always thought of it as three parts, but it sounds like it's actually four. It's consensus for DA, consensus for state, DA, and settlement. Wow. Guillermo Angeris: So yeah, maybe let's disambiguate, right? Like Blobstream is, I think that maybe here's another way of describing it that may also be useful, it's simply a way for Ethereum or I guess any smart contract chain, doesn't really matter, to verify that a particular piece of state is available to everybody. So the way we do like generally is you have some light client, and this is also similarly a question, so if you're afraid to correct me if I am wrong at any point. Nominally you have a light client and you're like I want to check if a piece of data has been posted to Celestia, right? And then you can create... Actually you can certify that that is the case, right? And if not, you could whatever, do some slashing. That's big brain. But the point is like, okay, cool, that requires... The problem is that requires you run a light client in your computer, but you don't want... Like you want to use the power of the magical internet computer that we call Ethereum to verify that a piece of data has been posted instead, right? So does not require anybody else to have this other secondary network that is verifying whether something is posted. And so this Blobstream is one way of being like, great, there is a contract in Ethereum and you can say, I promise you I posted this data. And then you simply say, and if you don't believe me, I will post this particular attestation to Ethereum and then it will indeed certify that I have posted the data more broadly. And if you trust Ethereum security, then you must trust that I have posted the data in the first place. And so of course that has a bunch of applications. This can be used to just remove the data piece from the L2 and simply post it on Celestia. So now we have removed one part that we often need to deal with, which is posting data to either Ethereum or some other... Essentially making data available, we have now removed that task and given it to Celestia in a verifiable way, in a way that you can indeed certify that like here you go, the data that I promised would be available is available, and you don't have to trust anyone other than essentially like Ethereum for that to be the case. Is that roughly correct? Yaz Khoury: No, that's very accurate. But to add to it, why would anyone want to do that? Why would you want to start modularizing, like moving components around and stuff? It's kind of like Lego pieces. But the biggest benefit is this is how you scale Ethereum, right? Because now layer 2s on Ethereum have way cheaper transaction costs because they're submitted... They have a really cheap DA layer they can submit their blocks through and they can verify that it's been attested to on Ethereum. And that gives them a lot of superpowers where now you can deploy a rollup on Ethereum and not worry about cost anymore because you have like a DA network that makes it really cheap for you to send your transaction to. Anna Rose: When you talk about sort of the efficient... Like making it cheaper, a lot of times, I mean, what my mind goes to, but weren't L2s invented to make things cheaper? Like, aren't they themselves supposed to just make it cheaper? Or are you making it cheaper for L2s to exist? Yaz Khoury: I mean, I can answer that question because there are multiple layers based on what Celestia solved originally, and based on what was the rollup-centric roadmap that Ethereum went through based on Celestia's vision, but still had problems without a DA layer. So I'll break it down into like, from the rollup side. From the rollup side, the idea that you can just deploy a rollup on Ethereum with no-cheap DA, doesn't scale Ethereum because what happens is, let's say it's a really successful rollup, right? It has some fun games, there's some, I don't know, NFTs, whatever the cool kid there introduces, right? That will create a lot of adoption. There'll be a lot of adoption on it. So what happens when you have a lot of adoption? You'll have a lot of high transaction costs. And that doesn't solve the problem of scaling, because you still end up where you started, where like, well, things are really expensive. What do I do now? Well, maybe there's another rollup that I can go to. You go to the other rollup, same thing. It's another chain that the more users, the more transaction there are, the more expensive it becomes. Anna Rose: Did they just get filled up almost? Like when they're empty, they're really cheap, but the more action, they kind of just catch up to the L1 in terms of gas fees. It's gas fees, right? Like for the user, they're noticing, oh, actually it's not cheaper on this L2 anymore. Yaz Khoury: Because there's demand, right? Ismail Khoffi: Might still be cheaper as if they would deploy directly completely on Ethereum. Like it might still be cheaper on that L2. But as Yaz said, once that L2 or once that rollup on Ethereum gets really popular, you compete again for data and state on that layer as well. So I think the key point here is specialization because if you have one layer that only does data, basically, like only does one thing, it ensures the data was published and the data is ordered, so there's consensus on the data, then there's no competition between state execution and that on that layer. So it's highly specialized and can optimize for exactly that use case, and the applications on top can focus on speeding up the execution. Guillermo Angeris: So fundamentally, what happens with L2s is that they become more congested. Like at the end of the day, what happens on the L2 has to be posted somewhere. And if you are simply on Ethereum, all you're doing is you're just passing the storage cost down to Ethereum, but that's still going to cost you the same as if you were doing the thing on Ethereum, at least for storage, maybe not for compute, but you could be running much faster, fancier, bigger computers. But for storage, you're still storing the same data that you were storing previously on Ethereum. And so that cost is always going to get passed back to you after enough usage. Anna Rose: This was the thing that's done by the L2 itself, right? This is the L2 smart contracts writing to the main chain, those check-in points. I mean, we've covered... I covered this years ago, and we did a series on L2s. So is it really... Is it those pieces then? Like is it that writing to the main chain that gets moved over to Celestia? Yaz Khoury: Not exactly because if Celestia were just another settlement layer in a different world, right, it doesn't solve that problem either. But what Celestia solved from a high level problem is what we call the big block problem, which is basically solving the blockchain trilemma, which if I remember correctly, it's like the trilemma. The trilemma includes... Is the triangle with security, decentralization and I think network uptime. Correct me if I'm wrong, anyone? I think that might be it. But anyways... Anna Rose: There's so many trilemmas out there. Sometimes privacy's on a corner, so I don't know. Yaz Khoury: Yeah. Guillermo Angeris: At this point, it's like a 6D simplex in some space with like 70 million faces and you can pick any triangle you want out of it or whatever. Yaz Khoury: Yeah, there's a lot of trilemmas. Anna Rose: But the one you mentioned, we can go with that one. Yaz Khoury: Yeah, yeah, let's go with that one. So basically it's the big block problem, which is, for a long time, you can see a lot of smart people can come into the space criticizing crypto and be like, well, if your problem is high transaction costs, why don't you just increase the block? I'm like Elon Musk talking about Dogecoin or whatever. And it's like, well, yeah, I mean, don't you think we never thought of that? We can just increase the block and stuff. But the problem with the big block is if you increase the block side, you centralize the network, because the costs of running a node exponentially increases. Anna Rose: Yeah, becomes so crazy. Yaz Khoury: And what Celestia solved there is allowed you to increase the block size while keeping the network decentralized. And that is through what we call data variability sampling. Where sampling from a high level, I mean, I can give an example of it later, but like a really simple example, but from a high level allows a light node to download or sample less than 1% of a block to get 99.99% certainty about what is included in that block. Right? So in a way, the way that we could provide cheap DA for these rollups is because if the blocks increase and they start getting billed, we can increase the block size as long as people are running and people are incentivized to run light nodes in order to ensure that we can continuously sample the blocks while keeping the network decentralized. Anna Rose: Cool. And I think this also speaks very much to the modular thesis, modular vision that you guys have been pioneering where you're not just making the block bigger, you're not just like, it's not like this kind of unsophisticated slapping a bandaid on something. You're like kind of dissecting out and then sampling... Trying to reduce it so that it's still correct without just bloating it. It's really interesting. Okay, I think we have a bit of a better sense for Blobstream now, although I have one last question about Blobstream. Again, we're kind of like my original concept and original thing we talked about with Mustafa had Celestia as not the settlement layer, but definitely like the center of rollups. Here, Celestia is interacting with another existing chain and so it's really providing DA, but it's not providing some of the other things it would do for sovereign rollups, for example, it sounds like. You sort of said it's sort of a product, but is it a set of smart contracts that you've developed? Is it something that if an app developer living on an L2 could deploy themselves on Ethereum, and that's what that is, is that sort of the product is just like a collection of smart contracts on Ethereum that interact with Celestia? Or is it more than that? Ismail Khoffi: In terms of software, it's mostly the smart contracts, but also they need to be in one component in Celestia that posts these data attestations to Ethereum. We developed that last year, but there's also a team, Succinct, that developed a ZK version of that, much better suited for this podcast. It's basically an optimization that proves the... Succinctly the consensus that was achieved on Celestia, right? Like then instead of the smart contract posting all the signatures and being also somewhat expensive, you can have like post a proof and that can be verified on Ethereum essentially. Anna Rose: What's the name of that team? Guillermo Angeris: Succinct. Anna Rose: Oh, Succinct. Yeah. Guillermo Angeris: Yeah. You've had them on that show. Ismail Khoffi: Great team. Anna Rose: Oh yeah. Wait, wait, it's BlobstreamX, right? Ismail Khoffi: X, exactly. Anna Rose: Yes. Okay. I'm familiar with this. Ismail Khoffi: Yeah, so these like the name is BlobstreamX, but it's essentially the same product. From a product perspective, it's exactly the same thing. Because for the user, it doesn't matter if it's ZK proof or it's like an optimized version of Blobstream basically. Anna Rose: I see. I have a kind of random question that may be very quick to answer, but do sequencers of L2s ever interact with Celestia or a DA layer? The way that I've understood... Like everything you described with like... I thought it was more like the app developer used like an app on an L2 that's actually using this DA. Or are you interacting with sequencers differently? Yaz Khoury: I mean, one way to look at it, like a model is like the sequencer interacting with Celestia is kind of in a way you want to abstract it, if the rollup interacting with Celestia. So the developer in that case is a rollup developer that's deploying a rollup. And that's interacting with Celestia. It's kind of like if you look at the cloud computing model, like if I'm deploying an application on AWS or Google Cloud or whatever, in this case, it's Celestia, we're providing infrastructure for that rollup. But from a user perspective, they don't really need to interact with Celestia. They're interacting with that rollup. That rollup could be application specific or something, but they don't necessarily interact with Celestia directly. They can if they want to, but I mean, it depends on the kind of user. Anna Rose: I think what you're saying though in that case, so this does go back to another conversation Ismail you and I had, which was this idea that the rollup is the app. That sort of lots of rollups, each one is an app. But I had this, I mean, when I say dApp, or I'm actually thinking of a lending protocol or something that is not a rollup. It's used to being deployed as a smart contract in an EVM environment. So it could be doing that on an L2, it's not creating its own rollup. In that case, would that app deployment actually be interacting with Celestia? Guillermo Angeris: Maybe we can think about it in some layers, right? Where it's like you have the L2 and then on top of it are a bunch of apps and the L2 itself interacts with Celestia. Anna Rose: So the apps on top of the L2 do not? Guillermo Angeris: Yeah, like they do, but through the L2. Ismail Khoffi: Indirectly. Anna Rose: But they're not deploying the contracts themselves. And I think this, just to go back a little bit, to rewind a little bit into this conversation, I think there was a moment where I was thinking more on that level. And this is a good clarification that like when you talk about an application on Ethereum, those smart contracts, those are always going to be rollups. So sequencers. They're not going to be the lending app or something, unless they want their own rollup, I guess. Ismail Khoffi: Exactly. But there are also almost like layer 3s on top of layer 2s these days, right? And these are more like their own chain, but they use the L2 to have quick access to that ecosystem of applications, right? And in that, they could also... So maybe I'm confusing you more now, but they could also interact directly with Celestia. So it's something... Guillermo Angeris: The rabbit hole goes deep. Ismail Khoffi: The answer, unfortunately, always is it depends, like how people use the stack, right? I think for a smart contract living on, let's say, Optimism or Arbitrum directly, of course, that developer does not need to interact or care about Celestia. But if you want to deploy more of a layer 3 on top, which I think all these big rollup ecosystems now offer in various ways, then you could post your data directly on Celestia as well. If it's something you as a dApp developer need to care about, I doubt it. I think you'd take something off the shelf that has Celestia integrated, like the solutions team that Yaz mentioned is working on that. And then they would write their dApp, launch their rollup in a rollup for layer 3 or whatever it's called, then their app would need to care about, but they would make a choice, okay, I want to post my data on this data availability layer or that data availability layer. Yaz Khoury: What I want to do is also contextualize what Ismail is saying on the, it depends part. So that's kind of the whole thesis around Celestia, right? Anna Rose: It depends. Yaz Khoury: It's so modular that you can like... And then when people ask us, well, what can you do with it? And you were like, build whatever. It becomes... Because you have so much option, like it's actually very liberating. You have developer choice first, whether you want to deploy your own rollup for your whatever NFT kind of application, or you want to deploy an NFT application on an existing rollup or any other kind of structure that you want, it depends on what you want to do. And this is why we say build whatever. Ismail Khoffi: So we're basically adding more to the trilemma, right? Like there's more choices you can do in the sense like how much you care, for instance, about upgradability and sovereignty of your application, right? That I think it's something that's a bit underrated right now. People might not care enough about it right now, but it is an actual decision. For instance, if you deploy directly on Ethereum, you adhere to the fork-choice rules of Ethereum and everything, right? And if you are in your completely own Cosmos zone, you're completely sovereign, right? But then you have this own consensus and other trade-offs. Like Celestia basically enables you to not have your own consensus, but at the same time it still enables you to choose between different layers of sovereignty or tapping into existing ecosystems if you want to. Anna Rose: And you can like tap into different settlement layers or yeah. Because I do remember that, that the settlement layer is definitely separated, like Celestia is not providing that. But back then there was conversation about a potential settlement layer for the sovereign chains. Is that still on the roadmap? Is that still something that people want to do? Ismail Khoffi: I think there's at least two teams, or maybe even three teams that I'm aware of that want to build a settlement layer on top of Celestia. So it's not enshrined. So it's not that we would add a general purpose execution environment on Celestia, and then people would deploy their smart contracts there directly. But instead, it's like using Celestia for data availability, but there's a settlement layer on top. That settlement layer just uses Celestia. Or the applications on top of that settlement layer use Celestia, either directly or indirectly. You have the choice. So I'm aware of two teams, if not three. I'm not sure if the third team decided yet, but there are certainly people working on that. Guillermo Angeris: Is this is going to be a fair summary. Celestia is a useful primitive to build things on top of. And of course, that might involve many, many things that we haven't even thought about quite yet, which allows you to essentially choose somewhere along the spectrum of, you could build on Ethereum, and that means that you are bound by the laws set by God, I mean, Vitalik... Sorry, I mean, Ethereum, as the ones that are true. There is the other end of a spectrum, which like, all right, just get good and build your own chain, right? And just do all of the things that you have to do, "do all of the chain things." And now there's kind of an interesting middle, right? Which says, okay, great, you can have kind of a weird mix of the two where you have this in-between state that is kind of given to you by Celestia, it says great. You can build part of the chain, for example, in this case, logic rules for state transition. So when is a block valid or something like that. And then we'll take care of one of the parts of building a blockchain for you, which is data availability. It's like you can think about it as a weird, okay, now somewhere in the middle of a spectrum, and a spectrum might have many dimensions, you now lie here. Ismail Khoffi: Yeah, and that middle is also a spectrum. Guillermo Angeris: That's right. In itself as well. Correct. Anna Rose: And a trilemma, of course. Guillermo Angeris: And a trilemma and this six-dimensional simplex of triangles. Anna Rose: We should get a graphic designer in on this one, man. I want to see this. Ismail Khoffi: I just wanted to add that while it sounds complicated, it's actually quite simple, right? Like it's not while you have the choices, it's only you have to make them when you care about them and then you have the freedom to choose, but you don't always have to choose, right? I think it's also part of the DevRels team or solutions engineering team and to try and work towards good dev UX. I mean, it's not only their responsibility, it's also like external teams are building infrastructure such that you don't have to make these choices. So there's defaults and you can just click, like deploy and done. But if you want to, you can choose all the layers and use it as if it was like Legos, or you can use something off the shelf and use only add the tiny bit that you care about, you as a developer, you as a community, or you as a dApp developer, like that part that you care about, like as how much sovereignty do I want? Do I care about Ethereum as a settlement layer? All these choices, you can only... You only have to do them if you want to, right? That's the goal is like, there's only very good defaults, very good dev UX, and you can also just deploy whatever you want. Anna Rose: I just realized I don't actually understand, I don't think we've talked about, what are the fees for using this for Celestia as a DA layer? I'm guessing there is still some fee? And how does that actually get paid? Like, who receives it? If you're not... If you're sending, if you're kind of living partly on Ethereum, but you're using Celestia's DA, how does that payment happen? Ismail Khoffi: It depends. Anna Rose: Oh my god. You're killing me. Ismail Khoffi: But whoever posts the data on Celestia pays the fee. And that can be the sequencer. Could be the user, like if the user directly submits the transaction, which is possible. Like it's based rollups. In based rollups, you always submit like blocks or transactions directly onto the data availability layer. So it actually... It honestly depends who that party is. But the party that posts the data on Celestia pays the fee. Anna Rose: Okay, when you sample, when you do the sampling, is there any sort of payment there as well? It's just the posting. Ismail Khoffi: Yeah, it's just the posting. Anna Rose: Okay. Guillermo Angeris: So it also has like an interesting set of mechanics, which is that storage is priced separately from whatever compute, for example. The person who's storing has to pay a value to Celestia, which is totally independent of the value that someone pays for the compute that needs to be done on the data, for example. So I don't know. I mean, this is kind of interesting. Also similarly, how you've disambiguated resources, you've also disambiguated their pricing, which leads to kind of interesting downstream consequences, I assume. I actually don't know how L2s are going to deal with this. For the end user, I don't actually know what this looks like. Maybe they're just showing some aggregated price or something. Ismail Khoffi: I think it's just the actual sequencers that pay the fees currently. Their users do not interact currently with the data availability layer. I don't know if there's a based rollup deployed currently. Like maybe Yaz, you know, I'm not sure. Yaz Khoury: We, me and the DevRels, we had done something, but if not really, it's just like for fun, like a simple base rollup in Rust, but it's not ready. It's just like a hackathon kind of project but, yeah, base rollup would be an example of a rollup that interacts directly like from a user point of view, with Celestia. Guillermo Angeris: Yeah, so what I mean is that the sequencer itself needs to charge the user enough for whatever data they, whatever state they are touching or whatever data they're touching. But in some sense for the sequencer, the data cost is disambiguated from the computation costs. Ismail Khoffi: Absolutely correct. Yeah... Guillermo Angeris: Put on Ethereum. Ismail Khoffi: Yeah, that's correct. And I think like, how the applications that are currently deployed handle this is most of these protocols either have a token or some business model and they don't ask the user to pay the fees directly and say they pay the fees and their protocol revenue is generated in their native token or however and that's how the paying of the fees is subsidized so to say. Guillermo Angeris: The sequencer as it earns money essentially like part of that is set aside to deal with separate fees from Celestia and similarly separate fees from whatever and say it's an L2, so whatever the fees that the L1 would charge for whatever service it's providing. So, yeah it's kind of interesting. I mean, it also like foreshadows all of this crazy stuff that's happening with like EIP-4844 and all of this any number of Ethereum initiatives in this vein. So it's kind of, it's an interesting set of consequences that are downstream of having two separate services for each of these. Anna Rose: I kind of want to expand on, like so the modular stack in a way, I think you guys pioneered that idea and that narrative, but are there additional pieces of the process? We've already talked about consensus and DA, and settlement, execution, state, rather, so are there other things that you think could be pulled apart in the future? Yaz Khoury: Guillermo and I and Mustafa, we actually kind of brainstormed a modular P2P network over dinner in London. That was a really fun conversation, but I thought it was really... Because peer-to-peer like as a network itself, because like different nodes peering with different nodes, it's just like, it's not really structured in a way. It doesn't have to relate to Celestia necessarily, but just in general, how nodes communicate with each other could be really improved and stuff. Anna Rose: Interesting. Yaz Khoury: And seeing more modularization or improvements on the peer-to-peer stack would be really cool. Anna Rose: I want to talk about the CIP process. Because this is, you kind of compared it to the EIP process. This is the way that Celestia changes. I guess the reason I wanted to bring it up is that I think depending on how far along you are with that process, it sort of gives us a sense for how far along you are in kind of decentralizing the power and giving it to the community to make those decisions. The network launched, what is it, like... Yaz Khoury: Halloween. Anna Rose: Three months ago. Yeah, so it's still pretty fresh. Oh yeah, Halloween. We didn't dress up, it was very silly, but we thought about it. Ismail Khoffi: The launch was not that boring. Anna Rose: But are people already using the CIP process? Is this something that... Actually is it CIP process or am I saying process process? Yaz Khoury: No, there's Celestia Improvement Proposal Process. Anna Rose: Process. Okay, fine. Guillermo Angeris: Yeah, it's good. Anna Rose: But can one already do that? Or are you sort of just in the process of... process process... Are you just in the moment where you're actually building that system? Yaz Khoury: The CIP process as it exists today definitely going better than I expected and stuff. I'm actually surprised in the sense that if the question is about, do we have external core developer teams participating in the process? Yes, absolutely. So currently, there are four working groups, right? There's the main one for core and consensus, and that's where we have the core developer call and people can watch it live on YouTube when we have those meetings. They're very transparent and stuff. And this is what goes around all the specifications that goes into Celestia, at least from a consensus point of view, if we want to activate a hard ware, to activate those features and introducing the concept of rough consensus, which exists in the EIP process, it exists in the PEP process for Python, it existed... It's like a passing of the torch for these kinds of specification working groups, right? Then we have other one. There's an interface one, working group and that one has external teams like Astria participating in it. It has Eiger, which is building a Rust-like client for Celestia's DA network. And then there's the DA working group, which is just two different teams. There's the Celestia Labs team with Celestia Node and there is Eiger. And then finally, and that was announced like a couple of weeks ago, you guys might like it because it's related to the podcast. There is a ZK working group by Zaki and Skip. Anna Rose: Oh yeah. We know about that. Guillermo Angeris: I don't know about this. Yaz Khoury: Yeah. They announced they wanted to do a working group, I believe two weeks ago. And they had their first meeting last week. And there were like 60... No, 50 people attended that meeting from all over the ZK world and the Cosmos world. It was really, really cool to see. Anna Rose: A bunch of ZKV people were in there, actually. Ismail Khoffi: Yeah, that's awesome. Anna Rose: This is our kind of thing. Guillermo Angeris: Damn, I'm sad I missed this. Anna Rose: Well, it's just the kickoff. I don't think it was like the finale. I think there's a lot of stuff to do. Yaz Khoury: Yeah, it was like the kickoff call. But Guillermo, I can add you to that group, it's fine. But yeah, so now you have a ZK working group, right? And now there's four working groups and there are even talks about maybe more depending on what rollups they're looking for and stuff. So we're already seeing a lot of interest. A lot of people want to interact with the process because they find it to be a really good process. And it's not like we're reinventing the wheel. It takes the best kind of practices from other processes that exist that are what define what we call off-chain governance, which is a superior way of governance around technical specifications because that way you have all the experts, all the core developers, all the research folks reading those specifications and going through a rough consensus process to decide what to add to Celestia for activation. Anna Rose: In the CIP process, so is that only for the outcome of these working groups? So like, first you do this off-chain and then... Like, is it on-chain? I guess this is kind of the question, like how on-chain is it? Ismail Khoffi: It materializes on-chain eventually, but in the sense that these decisions, if they're made and accepted by the community, it will materialize on-chain, but it's completely off-chain. Anna Rose: Yeah, the decision-making. Yaz Khoury: The on-chain part of this decision would be mostly like if the Celestia Lab core developer team releases a new binary and then activates a feature in the future, that would like make it on-chain if that's the question. I'm not sure if that's what you're talking about or on-chain governance. Anna Rose: No, no, I mean, the question is, is there... Do you plan on having on-chain governance and having the validators voting on some upgrades, or do you actually picture most of this happening off-chain in working groups, and then it's like the core team basically makes the call? Yaz Khoury: I'm very opinionated on it. I don't know if I'll get in trouble for saying it, but I don't really care. I've been saying it for a long time. I really hate on-chain governance. Like, my personal case is I know that there's more like a Cosmos community kind of thing, but I think like... And Vitalik also talked about it with a bunch of other people like coin-weighted voting for activation of technical features in a blockchain is a flawed mechanism because you're reliant on people voting with their coin who might not have the context on these changes compared to core developers who've been studying the network, the code, the specification, the research in and out, and they have a better decision making process around, would this screw the network or not if we activate it, right? Anna Rose: Yeah, I mean, I've definitely heard the arguments for and against it. I think having... Like existing in the Cosmos Hub and actually voting on a lot of these things, I've gotten to see it firsthand. Ismail Khoffi: And wanted to add one more thing. So Yaz dislikes the on-chain governance so much that he did not mention that there is a tiny component, there's like a subset of parameters that can be voted on-chain. So, and these parameters are mostly governance related parameters and a few... Like very few minor parameters of the chain that can... That makes like the memo field in a transaction how large should it be, like what's the max or how like... What is the min deposit for actually voting on any of this? You can vote on that. But that's... Anna Rose: What's the word for this? It's very internal. It's like you can change... In the clubhouse, you can change the color of the wall of the clubhouse, but it's basically a clubhouse. Ismail Khoffi: Well, there's one thing, so we have a hard-coded... In the software currently, hard-coded max of block size or square size. The current block size, you can change it via governance up to, I think, 8 megabytes max. And then if that's reached, if the community decided we need bigger blocks because there's so much demand for it, then there would be an off-chain process, the CIP process, to go beyond that. Because we know the current software can handle easily 8 megabytes. And we started with the most optimal block size and parameter, but that's a relatively important parameter that can be voted on via on-chain governance, but only up to a certain limit. And these limits are set currently such that there's a range where it makes sense. There isn't, for instance, like in other Cosmos chains, there's also you can change inflation. There was this huge debate on the Cosmos Hub, like if... Anna Rose: 848. Ismail Khoffi: Inflation should be halved. Anna Rose: ZKV tipped it. I was kind of excited. Ismail Khoffi: ZKV tipped it. Oh, nice. Yeah. That was like... Things like this, I think I completely agree with Yaz, right? Like I'm not advocating for on-chain governance. Like important decisions like that should not be voted on via coin-weighted voting, basically. Anna Rose: I'm like I wish I hadn't been like, we did that. Guillermo Angeris: We can cut it out. Anna Rose: Yay, on-chain governance. Ismail Khoffi: No, no, no, no, no. I mean, in the Cosmos Hub, there's no other way, right? There is definitely the right way to do it. It's not that you have a choice. I mean, the community has a choice. They could hard fork, right? They could say, I don't know, we disagree with the Hub's current inflation, and the community does not come to agreement on-chain, so we will hard fork the Cosmos Hub. And there were, I think, even initiated by one of the founders, I think, in Cosmos, right? There was a discussion of like ATOM 2 or I don't even remember the name, but there was a discussion around forking the Cosmos Hub. So there is a way, but that's only in case of like an extreme situation, an extreme emergency, so to say. So yeah, I think if this can be avoided and off-chain governance can be used is like much more preferable. And so far the experience with the CIP process that's like shepherded or like stewarded by us is insanely good, right? Like there's a lot of very constructive debate. People are... Like community is super eager to participate and improve... Like literally improve Celestia, right? So it's very nice to see. Anna Rose: Cool. I feel like we should chat a little bit about what's coming up, technically, product-wise, and maybe events. What's in the pipeline? Ismail Khoffi: I mean, on the technical roadmap, what is the biggest thing is like Blobstream deployment, right? Like Blobstream currently is not deployed. And that's a feature that the community needs to activate. But that will be the biggest next... In my opinion, the biggest next feature that's going to be live. Anna Rose: When roughly is that happening? Ismail Khoffi: Very soon. I honestly... But like not years, it's like rather weeks or something. I mean, it's up to the community to decide that, but I think there's audits happening in the background. I don't want to set a date because I can't decide it, but it's literally like probably weeks away. Then there's a lot of optimizations ongoing, both on the consensus layer, which means working on comets or tenements, P2P system. The mempool is being optimized. There's also CIPs about some of that, like there's proposals. I think there's already 15 proposals, if I'm not mistaken. Another big feature that's being shipped is Pruning. As boring as it might sound, is actually very important for node operators. Again, there's a CIP for that and also a lot of optimizations on the DA layer. It's mostly about performance and stability currently. And long term is if there's more and more demand for block space, how do we guarantee that Celestia can still serve that demand? Right? We have this internal mantra, it's like one gigabyte blocks. And yeah, it sounds a bit insane, but data availability sampling would make it practical, at least, if there's many, many light clients, like billions, maybe not millions, not billions, but many, many, many, many light clients. And so while it's not planned to achieve that this year, it's definitely something we work towards. I think that's like from the technical side, optimization, stability, Blobstream, Pruning, and then long-term make it possible to have one gigabyte blocks. Anna Rose: Cool. All right. What about on the products and events? Yaz Khoury: Adoption. Anna Rose: Or adoption. Yeah. Yaz Khoury: Yeah, so, I mean, yeah, we can summarize all of that and do like an adoption kind of setup. So just to carry a little bit more of the technical stuff from the adoption point of view, more integrations are coming, like we're actively working on Polygon CDK integration. And I think, was it this week or last week? I don't remember. Like, Starkware announced integration with Celestia, so there's active work on that, that's being scoped. From the rollup deployment side, I mean, they're like Layer Labs Finance, they're Manta Pacific already deployed. There's Upnode, which is like a gaming kind of rollup. And we already can see, like Manta Pacific, I believe there's a tweet by Manta Pacific about, like within one month after migrating to using Celesita for DA, they saved like a million dollars. A lot of people using OP Stack deployment. Rollup as a service providers, like Conduit and Caldera, we're seeing a lot of adoption because now with one click deployment using Celestia for DA, you're seeing a lot of interesting people trying to migrate. PGN, which stands for Public Goods Network, is actually shutting down. It's like a project within Gitcoin. But even though they're planning to shut down within six months or something, they migrated to Celestia just to save money while they shut down. Anna Rose: In the meantime. Yaz Khoury: So you're already seeing really interesting, kind of like cool things happening on the adoption side. And Lyare Labs, after they went modular, they started generating sequencer profit, right? Someone shared about Layer Labs, like the profit kind of goes down and then they switch to Celestia for DA, kind of climbing up again and stuff. So to wrap it up on the adoption and product side, there's a lot of different integration that are being scoped out. A lot of different rollups that are waiting, like they're going to deploy on Celestia. And there will be more interesting use cases for gaming rollups in the future, because now playing a game is really, really cheap when you have a gaming rollup that uses cheap DA as a resource, right? And yeah, I mean, that's what's currently scoped out for the rest of the year from the product integration and adoption side. Anna Rose: Do you have any events planned? You sort of mentioned this hackathon. Is that live? Yaz Khoury: It's not live. So we haven't announced a hackathon, but we are coming up with our own concept for a hackathon. So one of the problems that I see with modularity at least from a community point of view is, it's like this big infinite canvas and you want to get started painting and when we're like, modularism not maximalism, so like, okay great, we're modular, we're you're all about building and stuff. But there's no sense of belonging, right? Anna Rose: Or like a single line to like... There's no one path that people are supposed to do. Yeah. Yaz Khoury: Exactly. It's like we're that thing that kind of hooks you for a sense of belonging while you're happy. And when you say build whatever, it's great because it gives you a lot of freedom, but it's kind of like watching Netflix, where you have so many options, and I spend more time deciding what to watch than what I end up watching, you know? So what we want to do with the hackathon, it's going to be an online hackathon. We're going to announce it hopefully early March around that timeline at the first version of that hackathon. But I want to introduce a little healthy tribalism into the hackathons, just to make it more competitive between hackers. I can't say any more. It's going to be really fun, really exciting. And yeah, I mean like, there'll be like a ZK track that we can collaborate on, Anna. Anna Rose: Sounds good. Yaz Khoury: The other things that are happening on the community side, so I'll go from the smaller grassroot one to the bigger one. On the grassroot events, we have the modular meetup program. And now that's spreading like wildfire where last year we had about 12 meetups around the world. The past week we had two meetups and we have like four planned only for January and February. One was in Nigeria, in Warri, Nigeria. The other one was in Zagreb, Croatia for this year. We have one planned for Buenos Aires, for Barcelona, for Lagos. I think there's one for Istanbul. Like a lot of... So the idea behind the modular meetups is my experience with other L1s is when it comes to community building a lot of time you'll find like organizers come up to you and they'll be like well, if you pay me a grant, I'll set up a meeting for you. Like a meetup for you in my random part of town and you know, that's fine, but what do you get out of it? It's not really community building, right? It's just like pay-to-play kind of community psy-ops, if you will. And what I was interested in is I wanted people who are actually committed to the vision of modularity, people who actually are passionate about being community leaders in their own local regions and start building something before I can even consider sponsoring them. And the advice I would give them is like, well, you don't have to find a venue that you got to pay for, you don't have to do anything fancy. First, try to see how many people are interested in modularity. See the side of your community and the easiest way to do that, go meet up at a bar and just invite people. It's not going to cost you anything. Right? And that's what happened with the modular meetup in Paris. What the organizer brought people to a bar and they had like a quick presentation on modularity, then they had modular trivia games, right? And the people had fun and stuff, and then you see a lot of people in attendance and the guy is energized to create more modular meetups. So we're seeing a lot of interest there, and it's my target for 2024, 22 modular meetups, so double last year. I think we're gonna hit that number. After that, we're doing what we call the modular day series, which is one-day conferences that could happen at different conference circuits. So we had one in Istanbul last year, we're scoping one out, I think, for Denver. And there might be another proposal for somewhere in Europe. So that one can be like a one-day kind of conference around modularity and stuff organized by community organizers. And finally Modular Summit 2024. Anna Rose: This is what I wanted to know. This is my real question. Yaz Khoury: I'm building it up for Modular Summit 2024. Anna Rose: I can't be like, when could I interrupt him to say, when Modular Summit? Yaz Khoury: I wanted to build it up. Guillermo Angeris: You want to build up the excitement. Yaz Khoury: So the Modular Summit 2024, like when we're talking about the Meetups and that Modular Day Series, you can think of the summit as a pilgrimage for everyone around the world to go about one time per year for that flagship event where they can talk about, like all the brightest minds talking about not just modularity from the infra point of view, but like all the different subcomponent, all the different topics. So last year we had a really successful one, Anna, as you know, you were curating the ZK track for it. Yeah. I mean, this year, if you're open for it, I'd love to get you to curate it again, this stuff. We're thinking about a three-day event. We know where we're gonna do it, but we can't announce it yet until we finalize some of the details, but it's gonna be somewhere in the summer. It's gonna be bigger, we're gonna go way bigger this year. It's gonna be a lot more fun and we're still gonna go with the same kind of concept around allowing different people with their own sub communities and topics to curate it and stuff for the main stage and I think that's what made it special last year. Anna Rose: Amazing. Well, thank you for that little kind of hint at what is coming Yaz, really appreciate it. I want to say thank you to both of you for coming on the show. Thank you, Ismail, for coming back on the show. Yaz, you got to be on the show. I'm so happy. Yaz Khoury: Thank you. Thank you for having me. I'm very happy. Guillermo Angeris: It was pretty fun. Yeah. Anna Rose: Nice. Yaz Khoury: Yeah. Ismail Khoffi: Likewise. Anna Rose: All right. Well, I want to say a big thank you to the podcast team, Henrik, Rachel, and Tanya, and to our listeners. Thanks for listening.