We sit down with Eric Wall, CIO at Arcane Assets, to discuss all things Celestia, modular blockchains and the future of the L1 landscape with Celestia labs team members Mustafa Al-Bassam, John Adler, Nick White, and Ismail Khoffi. Moderated by Ekram Ahmed.
Podcast platforms
Timestamps
0:00 Start
1:08 Introduction to Eric Wall
4:34 Brief overview of Celestia
7:27 Changes in the L1 landscape over the last 12 months and predictions for the future
21:52 Cosmos, Celestia, and app-specific chains
27:08 Implication of congestion and fees on Celestia
32:30 Capacity of Celestia and modular blockchains
36:34 Data availability sampling and how it works with light nodes.
46:36 Can the number of sampling nodes in the network be measured?
48:25 Do nodes have to be aware of other nodes that are sampling?
51:24 Celestia’s guarantees for data retrievability
58:39 Value accrual and token abstraction in the modular stack
1:04:19 Can Celestia light nodes govern the block size of execution layers?
1:08:54 Is Polkadot’s relay chain a data availability layer?
1:10:45 Integrating a rollup with Celestia and data availability guarantees
1:16:06 Settlement interoperability and CosmWasm
1:18:40 Security of a modular multi-chain future
1:22:34 Data availability costs and the realizations of separating the data availability layer from execution.
1:24:56 Eric Wall’s thoughts on Celestia
1:27:33 What can Celestia do if usage hits capacity?
1:35:15 Restricting the settlement layer
1:37:35 Ending
Social links
Resources
And Eric, thank you for joining us, you and I have chatted in the past before. And I know you have some really strong convictions about the space. Let's go into some introductions. I'll introduce the Celestia leadership team firs so each of you guys just give like a quick of like who you are and what you do at, at Celestia and Mustafa, we'll go with you and then we'll go to the others.
Hello everyone. I'm the CEO co-founder of Celestia labs. Sweet John. Hello everyone. I'm John Adler. The chief research officer and also co-founder of Celia labs. Great. And then Nick I'm COO of Celestia labs, and then we are supposed to have Ismail who's the CTO. But I think they'd be joining shortly.
Cool. And then let's kick the ball over to Eric, Eric not only introduce yourself, but tell us a little bit more about your core focus. Now, a lot of folks may not know who you are, would love a quick. Eric intro. Okay. Sure. so I'm Eric Wall. I'm the chief investment officer of AE which is a Scandinavian cryptocurrency investment firm.
So I think, I think John sort of popped up on my radar in, was it 2018 or 2019? And I think I remember very clearly that John sort of pick popped up as this character that also was very interested in heavily criticizing various cryptocurrency projects. So my mission at that time, like the thing that I was focused on the most was trying to identify the absolute weakest link in, particular blockchain stacks. So we'd look at things like trying to identify, like where is the point of centralization in this system?
And where's the scalability bottlenecks in that system. And John sort of popped up in this context and also shared that interest. And I think that was around the time where I was known as the old coins layer was back in 2018, 2019, perhaps a bit in two, in two, 2020. And I remember clearly that he tweeted out like John's name and said like, if you want to look at what a good Ethereum critic looks like, you should look at this guy and he linked to John's account.
And after that, me and John we've sort of been sharing nodes on identifying like we, we looked at, for example, like hetero hash graph their claims about their scalability, and then comparing that to what the actual reality of the, of this situation is.
And I suppose the big difference here between me and John is that John then went out to say, oh, okay, I'm going to go and solve those problems. So John took the path of actually like not only like identifying the problems, but also trying to come up with what is the most logical design wise solution to those issues as well.
Whereas I've just remained as this unnecessary, non like non-productive complainer that just criticizes things. But I suppose, I mean, now that we're here, I suppose that John and the rest of the Celestia team recognizes that even though that. I sympathize with a lot of the, the design, the decisions that Celestia has made, that doesn't preclude me from I'm going to do the exact same thing that I do against any cryptocurrency protocol, which is, I'm going to try to identify the worst thing about Celestia and then just stick on that thing and try to, and try to squeeze out as much information about how the Celestia thinks about that.
So I'm going in here with the gloves off and I mean, that comes from, I think people sort of had to understand that now that I've explicitly said that I like the Celestia project, it just means that I have to criticize it twice as hard in order to like, keep the credibility in this situation.
Thanks, Eric. And a lot of folks don't actually know what Celestia is and, and all that Mustafa. Can you give a quick introduction of Celestia and the project?
Sure. So like TLDR is Celestia is a very basic layer. One that does the core components that layer one should do, and does it very well and nothing else. And that is basically, consensus and data availability. So you can think of Celestia as a blockchain where you can basically dump data on it and it orders that data and makes it available.
And it's, and it does it very scalably using a primitive called data availability sampling. And this is, effectively within the blockchain philosophy where Celestia sits at the bottom, that stack. And then you have execution layers that are, that can be based on rollup on of Celest.
Thank you myself. And it looks like Ismail just joined Ismail. What happened? And then give us an introduction as to who you are. Yeah, I'm the CTO of Celestia labs and I'm apparently not able to join the first space as a speaker because I joined on the desktop that happened. I was in the Twitter spaces since like the moment you started it.
Apparently, John just wrote me that it gives you a pop up that it doesn't work on web, but I didn't see that. Oh, good man. Glad you made it. Yeah. And let's get into it. Yes. So I'm going to frame the conversation and then we're straight up going into a debate and our strongest opinions. So when I look at the L1 landscape, I see a lot of noise and a lot of that noise conflicts.
I've gotten to the point where I don't know what to believe and not to believe. So I wanted to host this conversation to understand some of the myths and the truths going around. And from what I can tell, there's a lot more myths and misconceptions in the L1 space than there are truths. So in the next 45, 50 minutes, we will cover the major trends and forces at play that are shaping the L1 space.
And then we're going to talk about where everything is going. So we'll constantly be going back and forth between misconceptions and truth. And then ultimately the end game, we'll talk, congestion fees, induced demand, bottlenecks, scalability, all sorts of things. Now, speaking of fruits I think it's famously said and written that the only truth and constant in life is change and will begin there.
And the question that I'll open up for the group is what is the single biggest change that has happened in the last 12 months? In the L1's face, and then what's going to be the single biggest change that will happen in the next 12 months. Eric, why don't we begin with you? What's your point of view? Well, I think it's quite obvious and this is not a change.
This is just like, an outcome that was already bound to happen from the start art. So I think that a lot of people in the cryptocurrency space, they noticed of course fees going rampant on Ethereum and then that has led to general mistrust towards the theory project, whether or not it is, it is the ideal solution to facilitate DeFi.
And then we've had all these other layer ones pop up like avalanche and Sana. And many of them are based on the same premise that if you just increase the throughput capabilities of these systems, then fees will go down. So the, what we can already see is that fees are going up on, on avalanche.
And I think that the general principle here is that the more that lock space becomes valuable, the more demand will be created for that block space. So it's not necessarily, so it's not necessarily the case that the reason that the fees are high in Ethereum is because the block space is limited.
It's more, it has more to do with every, every single block in there. There's a valuable transaction that you can make. You can claim an NFT Arb. You can liquidate someone's position. And there's a, there's a, a dollar value in, into making those transactions that is worth spending in four of gas fees.
And if you increase the throughput so that you'll have just bigger blocks in Ethereum then you're going to, you're going to, well, it might decrease fees in the short term, but it's only, it's also opening up the door for more protocols to launch on Ethereum and also, and create more errors and more liquidate that you can trigger.
So the conflict that is here is, is whether just increasing the throughput actually decreases fees. And I think that the salon system, they, they have one a different way. Of managing congestion where they don't actually have a me. So you won't see the same type of, of gas bidding in the wan me pool because they just drop the transactions if they don't get in, in a timely manner.
But what happens instead then is that you can't actually use the Swan system because they're dropping the transactions and then they have outages instead of fee spikes. So there's, they, they have liveness issues in two different ways, either the fee spike on like platform spike, Ethereum or, or avalanche, or you have outright outages.
So you don't necessarily see those fee spikes. But what we can sort of understand from this is that no one that just focuses on scalability or just throughput at, at the base layer is actually meaningfully addressing a long-term sustainable solution to the fee problem.
And I think that this year, like very recently, I think that the tone in the space and the interest is because, because we have seen that these layer ones don't necessarily address the problem in a sustainable way there needs, like, are there other ways to address these, this problem? And I think that Celestia sitting at the core of that, so you, even though Celestia is not live yet, it doesn't exist yet.
There's so much of the intellectual of the intellectual debate that is happening around the protocol. Because I think that everyone that has been in the cryptocurrency space for a long time is sort of understanding that at the base, at the root, at the basis of all of scalability issues, there is one thing that sits at the focus and that is data availability.
So if you want to scale some predator of these systems, then building a scalable. Data availability layer is where you should start now, what I'm not so sure about, you know is that a solution that, does that solve all the problems or is that just creating the optimal solution that also fails to solve the problem?
Thank you, Eric. Mustafa, we'll go with you next. What's your take? Yeah. So, I mean, in terms of the question, like what has changed in layer one space? so I would say like, if you looked like there was a period back in 2017, 2018, when there was lot of new layer, one projects that kind of raised big rounds like Avalon Alan near protocol and so on and so forth.
And a lot of them are kind of based around like a similar premise, which is like Ethereum but more scalable or like a more scalable share spot contract platform. In the sense that you have like a you have a synchronous execution environment where all transactions kind of run within this world computer model that Ethereum has kind of proposed like where there's this, world internet computer where all transactions are processed.
But now we've kind of seen the results of that play out. Like we can see 20, 22 that does not really work. Like you just cannot have a single synchronous world computer chain, like as, as a shared smart contract platform, like you've seen you know, issue, launch and salon and bang, manage chain, all struggling to keep, to cope with demand, even though they seem to be more scalable than Ethereum.
So I think the bigger shift we're seeing now is this idea from multi chain world, like. It's no longer a world. It's no longer a paradigm where there's a single blockchain that can synchronously process all transactions. Now people are realizing that actually you have to have a multi chain world. and that's like similar to the that's effectively the cosmos vision, that was kind of introduced a few years ago.
And Ethereum is also taking this approach because rollups themselves enable basically an implementation of a multi chain world because roll ops themselves are chains so effectively Ethereum’s heading, heading this direction as well, where, all the execution happens on rollup chains that connect to the Ethereum main kind of hub.
So I would say that's kind of the biggest shift, like this shift between a single world computer model to a, like a mini computer model where you have multi chain world, like where the chains communicate with each other. But obviously like there is no perfect solution. Like all scalability solutions have tradeoffs.
and like the biggest trade off of this like multi train ecosystem paradigm where everything is a rollup and all the execution happens of chain, is this kind of issue of composability like the great thing about this world computer model, where just, just run all your transactions SoSolana is that you have synchronous uh composability and yeah, you can just write a smart contract that calls any other smart contract.
So, but with the small car chain model, even though it's theoretically more scalable, the main drawback of it is that it makes composability more complicated. It’s not impossible or not too difficult, but more complicated and more tooling is required. Like for example, like we haven't, like I, BBC was only launched somewhat recently. And we are only kind of starting to see that kind of flesh out and see the potential of that.
John, let's get your point of view again, the question is what is the single biggest change that's happened in the L1 space for the last 12 months? And then what do you anticipate the, the next biggest change to be in the next 12 months? Go for it, John. Sure. So one big change. I saw the entire one space or just the blockchain space in general over the past year has kind of been an acceptance of the modular blockchain vision.
If you're listening to this, you should probably, at least have heard of it. But for those of you're not familiar, it's essentially the separation of data availability on the consensus layer and then doing execution at the higher layers. So the, kind of the acceptance that this is the path forward to get the best blockchain that you can get that doesn't necessarily best doesn't necessarily mean.
Like you know, it's, it's the most scalable in all respects necessarily. But that it's the best cross section of properties. I expect in the no next year. no, not 12 months starting from now, but like in a next year or so to see a large proliferation of execution layers because as we get scalable data layers such as Celestia launching we need something to execute transactions on and the something is going to look like a multi chain world.
Like at Mustafa said the original cosmos vision of multiple not just multiple, but many, many execution layers that communicate with each other. now that shared data availabilities layers like Celestia will exist shortly. this means that these execution layers can actually share security, which is an important property they were missing before Celestia came on the scene.
So you kind of get the best of both worlds or you get the scalability benefits of charting without all the complexities and shortcomings and open research problems of charting which isa large part of why various projects that were initially pursuing charting eventually gave up. cause it's various open research problems.
So I expect to see in the next 12 months wide proliferation of execution layers that do different things that try different things. Because now we can experiment with a variety of execution systems without having to worry about bootstrap, your own validator set, without having to worry about bootstrapping your own consensus network, you can simply deploy it as a rollup on top of Celia and benefit from shared security that all are the rollups.
Also benefit from additively. Ismail. Give us your take. Yeah, I think, I'm pretty much aligned with what, with DFA and John said here, there isn't much to add, I guess, especially coming from the customer ecosystem, for me, it's like particularly powerful to see, a vision coming together where you have application specific chains.
But instead, as, as John said previously, instead of, them having to bootstrap their own proof of stake BFT consensus networks, they can run as rollups on top of a data availability layer on top of Celestia. And, yeah, for me, that's going to be huge. And, yeah, I think other than that, I guess like every, every everything that John and Mustafa said, yeah, is just what I can align with.
Yeah. Okay. Yeah. Hema does have a, a Cosmos background and it's an interesting perspective. Nick on the other hand is coming from harmony, Nick, same question to you. macro changes last 12 months, next 12 months. What's your opinion. I agree a lot with Eric that harmony and I think the whole sort of like cohort of scaling solutions that were built from like 2017, 2018, until now, I think we've kind of seen in the last 12 months that they do help alleviate the demand for, for block space, but ultimately they don't seem to be like a viable solution long term.
And, I think that's also kind of led to people realizing why cosmos for example, has had the multi chain vision that you, you kind of need separate execution spaces, I think to have a scalable, sort of like blockchain infrastructure. And so I think the next 12 months are going to be sort of like the maturation and development of this modular blockchain infrastructure.
I think it's to be fair, it's still very early, right? So Celestia is quite far from launching main net. We have a bunch of rollups. Some of them are already live. Most of them are still sort of, being built. And I think in the next 12 months, we're going to see the ecosystem emerge and, and mature.
And I think a lot of people are going to start to realize that, I guess like this combination of a scalable data layer with sovereign execution spaces as rollups is at least so far the most compelling solution to, to scaling lot of other problems that we face with interoperability included in that.
So Eric and I were chatting, I think last week, and this question came up in our conversation, can Celestia address the fee problem. And it really caught my attention and ultimately helped trigger this conversation. I wanna go deeper on, on this topic of fees and congestion, Eric go a bit deeper, share some of your strongest opinions on some of the misconceptions around fees and congestion.
And so, and the underlying truths at play that many aren't seeing possibly. Sure. And I just want to, I think that we like failed to clarify one thing when we were talking about this previously. so we, we mentioned the Cosmos system and how they're doing parallel application specific blockchains. And I think we should need to clarify a little bit more how Celestia ties into that and sort of what the vision is. And I think one very interesting thing here was I was talking on Twitter about like two, three months ago broadly about what's going on in the blockchain space. And Zaki Manian commented underneath the tweet. And he said, didn't everyone just adopt my thesis from five years ago.
And I, that was kind of a stretch. So I responded to Zaki and I said, but cosmos felt thin until Celestia came along. And so Zaki responded that Celestia was the original idea that Jay and Ethan pitched to him and that they call it super tanker. and then Zaki said that it wouldn't work. And then Mustafa came along and invented data availability, sampling.
And now you all of a sudden. How exactly what cosmos was going for apparently five years ago. and I think what people need to understand is that when you have in a, in the Cosmo ecosystem, you have these zones, each zone is a blockchain and each blockchain has its own security parameters and validator set.
The problem is that If all of these are communicating with each other, using IBC if one of these chains are re-orged, then that causes problems for the other one. Basically you can Rob the bridge in these systems, if you break one blockchain, but, but not the other one. So what you sort of need in order to build a shared security for these applications specific blockchains, you need a shared security.
And that is because Celestia is a data availability layer, but it's also a consensus there. It's also a thing that can order the data that has been seen in the system into a chronological order. It means that all these there can't be reworks in one of these application specific chains, if they use Celestia as the data availability layer, because Celestia is creating this shared layer for all of the zones, which means that they can get shared security.
So I think that that's sort of very important to, to sort of understand how these things are coming together and why Celestia sitting at the focus of this conversation, but now to talk about, I mean, the reason, the reason why. The Cosmos project has been interesting is because the nice thing that you get from these asynchronous execution environments, like these application specific blockchains is that the fees can be very high in one of these apps, but it doesn't mean that the fees are going to be, to be high in the other apps.
So if you have one blockchain specific. Application specific blockchain that does something like Uniswap and you have another blockchain that just does payments. I mean, people are fine with paying high fees on under decentralized exchange because they're buying a token and they're hoping for the value to go up like thousands of dollars into the future.
You're fine with spending like say five or $20 to, to enter that position. But if you are making a micropayment, like a micro transaction in another chain or, or yeah, if you're doing it in another chain, you, of course you want the fees to be low in that other system. and the problem that these systems like avalanche or now avalanche has segments, but generally speaking, monolithic blockchains that, or have a single execution environment in these systems you, you, you don't want the fees of one application to drive up the fees in other applications because that's how things become unscalable.
So, What, I want to discuss with Celestia here on what my sort of, dilemma or puzzle is if there is, let's say there is an application specific, like an app, an app that runs on Celestia through an execution environment, through a smart contract, it runs with uses Celestia as a data availability later, if there's tons of demand for that specific application, then that creates block space demand on the Celestia base layer.
And this impacts the entirety of the Celestia system, because while Celestia has tons of block space, it is not infinite. So if we get one very, very application, very, very popular application that uses Celestia. What I'm, what I'm trying to understand is whether that leaks into all other Celestia using applications such that if you have a micropayments.
Application that also uses Celestia as the data available layer. Is that fee pressure going to leak into the other applications? I think that the obvious answer sort of is yes. Right. But we don't really know how bad can that get, like what if there is one application they so popular that it just the fee, it, it drives the fees up on Celestia to $5 per, per transaction.
Like, is this a, is this a catastrophic scenario for Celestia or is that still viewed as a positive outcome start please? Yeah. So yeah, I'll, I'll respond to that, but I also want John should also, I'm sure. John also has lots of opinions about this. so the, so the short answer is, yes, like like first of all, like no blockchain can guarantee cheap fees.
If any blockchain guaranteed cheap fees, then it would be vulnerable to denial service attacks cause like someone could just spam it with free transactions. so like in Celestia and, and which includes in Celestia and every other blockchain that is not one to service attack, there is a block size limit. Now the question is what is that block size limit several questions here. So first of all, like what is that block size limit and how do you, how do we pick that block size limit and how does it scale? And, secondly, like what is the maximum potential size for that block size limit compared to like another thick blockchain like learner for example.
So one thing I've said before is like redefine scalability as equal to the number of transactions or the throughput that blockchain can handle divided by the cost, for an end user or like client to validate the correctness of that chain. And this is the fundamental reason why, for example, Ethereum or Bitcoin would not just increase the block size to something in significantly high, because like end users would not be able to run a full node to check that the chain is correct.
Now, this is, this is kind of contrary to Solana for example, where Solana have taken the approach where they don't care about end user verification. And they just wanna scale throughput, as high as possible on the monolithic chain. For the bottom part of the equation, which is the cost for end user to verify the chain.
The property in Celestia is such that, because we use a primitive called data availability sampling, the more users there are in the chain the more likeliness there are on the chain doing availability sampling, then the higher, the block size we can, we can, we can increase it to like see safely without compromising the ability for end users to verify the correctness of that chain.
Or in other words, to check that the chain data is fully available. and that's because data availability sampling any, and any like client can verify that the chain is fully available by only downloading a very small piece of that chain. So that's one-sided equation, which is that we can scale with number of users.
Or like any blockchain, including any blockchain that supports data availability sampling can scale end user verification with a number of users. But then the next question is, so like scaling end user verification is all well and good, but how about like increasing the three point of the chain or the block production of the chain?
So in Celestia I would argue that we fundamentally higher in other systems like Solana and the core reason for that is because the validators on the Celestia chain, they don't do execution of the users transactions.
They just do data availability. And so, which is a very bandwidth heavy resource requirement, but not computation or kind of memory, heavy requirement. And the fundamental difference here is that, like including like just providing data availability is a stateless operation, which means that you don't have to like, remember any user state.
So like for example, in Solana you have to have a huge amount of memory. I think it was like 256 gigabytes of memory to run a validator there. Because you have to remember a huge amount of state. For example, user balances, you actually validate blocks. But in Celestia because we decouple the availability and execution, the actual validates of the chain.
They don't have to maintain state. They just have to put, they just have to have the bandwidth to receive transactions and put them in blocks. And that's fundamentally allows you to increase block production to much higher, than if the validators all has also have to do execution.
Yeah. So what Mustafa said is kind of one of the key distinguishing factors that makes the modular blockchain architecture so compelling that for the first time ever you know, we can have this decentralized network that can actually grow its capacity as the number of users grows the mono effect, blockchains that you see in like Ethereum, Solana, and Bitcoin, for example these all, as you add more nodes, as you add more users, you don't actually get more capacity.
Now one subtle point here is that the cap, the specific capacity that's growing as you add more users is the capacity of data availability. It's the throughput in bytes per second, not in transactions per second. And this is actually one of like a litmus test. If you want to see, is a blockchain modular, or is it monolithic?
If it advertises transactions per second, then it is not modular. It is monolithic or it's an execution layer as part of the modular blockchain stack the base layer of the modular blockchain stack, the data layer does not support. Transactions per second. It supports bytes per second. Now unfortunately these bytes aren't actually interpreted by the data layer.
So even though you get more capacity in just data throughput, as you add more nodes that does not imply that you get more capacity in execution, the execution is still bottlenecked by whatever parameter decentralization you set and by the particular choice and implementation of virtual machine and transaction format and so on.
So if you put Ethereum’s EVM into a rollup that does not imply magically, you can get my more TPS out of it. If you want to get more TPS out of that EVM in a rollup, regardless of if you use Ethereum more Celestia as a data layer, you need to sacrifice something fundamental. You need to sacrifice some security guarantees.
Or you sacrifice decentralization, which is all not necessarily good. It could be some trade off that some users are willing to accept. but ideally we would like to have the option of a highly decentralized and highly secure, the same decentralization security that you get today blockchain or several blockchains, and have that also be scalable.
And you can do things like have a charted or sharding without charting you know, multiple blockchains running in parallel, multiple develops running in parallel, or you could have one rollup that is more efficiently engineered can provide composable like a higher throughput of composable execution over this scalable data layer.
So the kind of the TLDR of this is that having a scalable data layer is. A very well, it's very important as the base. If you don't have this, then if you have a monolithic base layerthat cannot grow as you add more users, you're going to be heavily restricted and the total throughput of the system, but that's only half the puzzle.
You also have to look at the other half, you have to look at the execution layer. And for that, this is why I said in my answer previously, I expect a proliferation of a large number of execution layers that all experiment with different execution models because we would like to have something that is, that has the composability of things like Ethereum, but that also is also verifiable it's an execution layer.
It can have fraud or validity and act as a rollup so it can share security with all their execution layers on a shared security base layer, like. Eric, we'll let you react to what Mustafa and John just said, okay, good. Because there's one thing that I really want to bring up here and it's something that's been bugging me for a while, and it's good that I have all the four of you here to sort of address this question.
So I've heard I've John just said that in Celestia capacity increases with the number of users. And this is something that I think I've heard Nick also say in the past, like he said that. The more users you have, the more they sample and the more the security they give to the network. And so I suppose that the way that the Celestia team is thinking about is that if you have more users and they're doing data availability, sampling on Celestia, which is the thing that you, you got a sample, that data is know that it's there.
And the more users you have, the more sampling you do, which means the overall data can be the overall data set can be larger because you now have more samplers. So there's two things that I would really want to get help with understanding. The first thing is the first thing is I think it's an easy one.
I just want to understand, like, okay. So if I'm a user and other users are sampling how does my node get the information or verification that the other nodes actually have sampled the data. Are there small proofs that they deliver or can you just go into some detail into how that something goes?
And then the other thing, this is the most important question I think maybe that I have in this conversation is that okay. Yes, with more users, you sample more of the data. the data can be larger, but John, I mean, you have been the one, the person that has always been saying that unless the security assurances are constant, as you increase throughput, then you're not actually scaling.
So in order for a system to scale, you have to scale while maintaining the same level of security. And now my issue now becomes is that okay. Yes. you can, by using data, availability is happening. You can, you can prove data availability, but you don't actually prove retrievability, and in order for the system to be secure, you actually also need to retrieve the data. So just, just knowing that the data was published at some point, doesn't actually give you the security that you can create a fraud proof or create validity proof and get your money out of the system. You need that data to be there.
So isn't the only real full node security still based on that, you have to have all that data. Yourself on your node, otherwise, you mean there are other node. You can know, that they have sampled the data, but what if they all turn against you at one point? And you mentioned that in cosmos there's the Tendermint consensus algorithm, there's a maximum of 100 or 200 nodes.
Are we trusting these 100 and 200 nodes to make, contain that data? And if they go rogue, then the end user is screwed. And the more data that is getting pushed into the system, then that still puts the bottleneck in terms of how many of these nodes are actually storing all the data. and because, I mean, it's, it's one thing to have the proof that the data was sampled, but it, it's another thing to actually know for sure that when you come to a point in time where you need to get that data out of the system, it is actually going to happen.
So let's see a team who would like to respond. I guess I can, I can start. so maybe it'll be helpful first if I kind of. Give a quick overview of the properties of data sampling and how it kind of works in general. So the general idea of like the problem that data availability sampling is trying to solve is as a user, how can I make sure that let's say some megabyte block was actually published to the network by that block producer without me having to actually manually download that entire block myself and check that it was actually published. So this is basically preventing, what's called the block withholding attack where a block producer or a validator might publish in a block header but if they don't actually publish the transactions that that block header points to then people might not know what was actually inside that block. And so if there was an innovative transaction in that blog, then they would not be able to detect that. So with data availability sampling, it basically allows a user to download a very small piece of that block and get a very high probability assurance that 100% of the block is available.
And the way it roughly works is I'm not going to go too much into the weeds, but that the way it roughly works is the block producer splits the block into hundreds of chunks and applies something called erasure codes on top of those chunks. Now, the end result with you don't without understanding how erasure codes work, but the end result is that as a light client I know once you apply the erasure code, if block producer wants hide even a single bite or even a single transaction in that block, it's not sufficient just to withhold that specific transaction or bite, they would have to hold withhold half of the entire block, because if you know, any half of that block is available the entire block can be reconstructed half of the available data.
And so this allows like clients to kind of have this sampling primitive, where if a light client or a user samples 30 pieces or chunks from a block then they can be 99.9% sur that 100% of the block is available. Because if the block producer actually did this attack and they withheld half of the data and the user randomly sampled or randomly checked 30 different pieces in that block, then there's very high probability that the user would have landed on an unavailable piece or withheld piece.
And therefore they would know the block is withheld. Now this kind of scheme only works if there's enough users in the entire network, such that they're all making enough samples collectively so that they can actually be construct or recover the entire block. So if you have 1000 chunks, it's not enough just to have one user requesting take examples, but you know, you need a bunch of users such that they all requested at least 500 samples.
So you can kind of think of it like bit torrent. If you're familiar with bit torrent, you have, you have peers and seeds in network and those peers have, might have different pieces of that file and they can all share it with each other and reconstruct it. and that's kind of the fundamental reason why you want to interrupt.
Yeah, I was wondering, so how do I, as a user doing the sampling, know that the other users are doing it? And if they, because I mean the other users they're not involved in the consensus, they're also sampling, how do I get assurance from them that their sampling is also benefiting me?
How does that compound? like you don't know because you, you assume that there are, and the reason why that's fine is because usually the number of flight clients needed are like in the few hundreds. so like if you have a one mega by block you only need a few, like, depending on the parameters of the construction, You wouldn't need more than a few hundred light clients for the assumption to hold true.
And so if you assume that the network has sufficient number of users or if you know that, then you would assume that there's enough, like users running nodes in network this assumption holds true. But that, that sort of assumes that if there's one node that is sampling and doesn't get the data, he's able to prove that he's not getting the data.
So is that something where the one person who's sampling fails he can flag it to the other node and they can try the same sample and see if there’s a response. So, this does not involve any kind of like flagging or proofs of unavailability or red alerts of flags. Like, the scheme works without that. Because if the user assumes that there's enough users in the network doing the same scheme as them and doing the same sampling as them, then that's all they need to know that data is actually available. Like, because the reason for that is because like, if there's enough users in network, to request enough samples to force the block, producer's hands such that in order for that block producer, to like for that block producers have to meet all of the sample requests. The block producer would have to release just enough of a block such that entire block can be reconstructed.
So one thing you might be thinking of is that there's no deterministic completely reproducible way for you to know for certain how many honest nodes are performing this data. But there's no concrete way of guaranteeing that that is true. This is one of the reasons that the kind of social consensus around Celestia is ultimately to use social coordination and off chain governance in order to control parameters like the block size limit. Because there's no way on chain of determining on not just on chain, but just programmatically in general of determining how many honest nodes there are in the network.
This is more something that the community can get together collectively and decide on these parameters, implicitly, deciding on how many honest nodes the community thinks are participating. So it's like, how is the maximum block size limit in Bitcoin determined? It’s a social contract between the participants of those networks, such that they a certain node resource requirement, and they upgrade the chains and set the block size limit rates on that.
I would argue that it's still fundamentally different though, because in Bitcoin, I don't need to rely on anybody else's account that the data is there because with the Bitcoin client, I download all of the data. So I have it on my own computer. Whereas in the Celestia system, I don't download all of those petabytes. I'm just sampling them and if the data grows and your argument here is that even if the data grows, as long as the users also grow and they're also sampling, then I don't have to worry about the data growing, even though I'm only sampling the same number of chunks. So what I'm really trying to get at is that if I'm always just sampling the same number of chunks and the data grows and grows and grows, then I have less of the certainty of data.
It sounds like there's this social element to understanding that there are other samplers around me, but that's not like a technical quality. So what I'm trying to get at is it scales maybe in a social sense, but that is actually scale in a technical sense.
Yeah. So, so that's, what can I also quickly add something? I think, I guess it, the. The sampling itself is a proof that the data is available and you don't need to know that. I mean, it's a local property and you don't really need to know that others are doing sampling as well. It's more that if the sampling succeeds, it's also proof that there is enough nodes providing you with the data.
Right. So I guess, like there's some confusion also. It's not the sampling only, but if you sample and also serve that data, then you provide security to the network. The sampling itself is also for yourself. But if you want to like, provide to the network, like to the security of the network, I guess you also have to release these samples right?
Maybe that does that clarify a little bit because yeah, but I have some other questions in along that if we can move on, like if you don't wanna spend too much time, but I have a few questions that we can perhaps try to address. So the other question that I have is that, okay, so when you sample a block, do you ever sample it again or is it just when that block arrives, that you sample it and then you assume, It has been published and then you have a look at it again. so if this block was published like two years ago, do you ever go back and sample previous blocks and get the certainty that those blocks are still there. Because your security can still depend on those blocks, right?
Yeah. So, no nodes that come online, will at least like light nodes will at least sample from the, from their, from their checkpoint or from the trusted header. You could also start from genesis and sample from there, right? Like, even if it's like two or three or five years ago, but, well, I think Eric's question is I think if I understand correctly, Eric's question is more about, do we also guarantee the ongoing availability of the block?
Like, is that right? Yeah. So this is like, this is a very common question. like the question of like data retrievability that people ask if we guarantee, and Celestia does not guarantee data retrievability. What Celestia guarantees is that the data was published at some point in time, the assumption that we make for data retrievability is like basically the same as an Ethereum full node which is that once the data has been published and =if you can verify that the data was published, then from that point on, there's an honest minority assumption for the ongoing reliability of that data. Because effectively if you can check that data was actually published internet, then for the ongoing ability, you just need to assume that there's at least like one honest, like no, like server on the internet, that's willing to, like host and serve that data.
Or like there's at least like one copy on the internet somewhere. And this is also why there's a block size limit. Like obviously that would not work if you have, like, tens of terabytes of data because people would not be able to host that and. But if you have a block size limit that scales with the number of users, then you're more likely for that assumption to hold true. The way that we want to design the system is that you can actually contribute to the storage of network without storing the entire blockchain.
So we have this concept of, of partial storage nodes that can store parts of the blockchain and contribute to part of the storage of the blockchain. Kind of like a bit torrent file with different peers, that whole different parts of file.
Okay. So my nitpick is the summary of the situation here would be that, I would say that yes, if all the in Celestia is one terabyte, then I would assume that this data is still retrievable and retrievability, in my opinion, is the security requirement, not just availability.
So if it's just one terabyte, I would assume This data is probably there, but if it's a, a million terabytes, then I would assume that the actual nodes storing all that data is much smaller. So meanwhile, it is commonly said that as users grow, you'll have more sampling and the security scales with the number of users.
I think that you cannot escape this harsh reality that as data grows, there will be perhaps fewer nodes that actually stores the data and the certainty that you can retrieve it shrinks. So I think like attaching when you're saying that security scale, with the number of users, you're really thinking about the data availability sampling scales with the number of users, but security is retrievability and retrievability is impacted by the actual size of the data.
So that's just like a nitpicky summary of the situation. I still understand that the data availability sampling does give you favorable properties here. But if you're going to the very cold, harsh truth of the situation, then thousands of petabytes of data on Celestia, you're going to have to rely on that data to still exist because you're not sampling it all the time and you're not getting proofs from other nodes that they have sampled it to your nodes all the time. At least not in the way that states design at the moment. Do you think that that's fair. Did I say anything that was incorrect there?
Well, I mean, I guess there's two things I would say to that. The first thing is like, what I've said is that is the status' quo of how blockchains work. That's the same assumption that an Ethereum full node makes.
And obviously that assumption does work. Like no one complains about the assumption as you write you say that's because we were talking about a few terabytes of data. But the question then becomes what if you have hundreds terabytes of data.
There's several things I would say to that, but first of all, just because we don't want to have on chain or in protocol incentives for data retrievability does not mean that there cannot be incentives for data retrievability. It just means that at the incentive layer for data retrievability and data availability is decoupled.
For example, Ethereum technically also has a data retrievability problem. Like that's why people pay Infura to get access to full nodes and to get API queries from Infura. You can think of Infura as a centralized data retrievability layer for Ethereum but obviously you can actually have decentralized versions of that.
For example you've got pocket network, which is more distributed and you have like the graph, which is retrievability for index data. And then you've also got data storage protocols for example, Filecoin has proof of retrievability. So, the first thing I would say, like there's no inherent reason to have data retrievability incentives as core part protocol.
The second part I would say to that is, like, even if that's not good enough, it could be the case that the like end user, the end user applications that people belong to last year could make their own assumptions about data retrievability. For example, they could create the retrievability assumptions within their applications.
But if this applications want higher are data retrievability guarantees they could add data retrievability or proofs of retrievability within their applications if they wanted to, even though I don't think it's necessary, but they could.
So I'm going to move the group to back to the L1 topic while I do that we will be going into Q and A. So if anyone wants to ask a question your chance will be soon. Eric, while we wait for Q and A is there another major misconception in the L1 space that you can point out that needs clarification or that folks need to talk about?
I have more like architectural questions about Celestia. Like I think one that would perhaps be more interesting to talk about if you don't mind. I think one of the very interesting things, when you're thinking about the modular blockchain stuff is thinking as investors and then most people in the cryptocurrency space are investors.
Everyone is thinking about, okay, where does value accrual happen in the system? And we didn't, I don't think that we really touched in this conversation is a good clarification of the different layers in Celestia. And I think these terms are also being mixed and confused sometimes. So if we like start by dissecting the stack into their appropriate layers and label them correctly, and then talk about which tokens do what.
And if you think, I'm taking the conversation into a direction that you don't want to go, but from my perspective at the base you have consensus and data availability. And those are actually in Celestia bundled together because the Celestia base layer orders blocks according to Tendermint consensus that it uses. And it provides data availability for that layer. And that’s the data availability layer, but it's also the consensus layer. And those two terms are being thrown around a little bit confusingly, but I think that that's really one layer. And then on top of that layer, you have the execution layer, and this is a system that provides an EVM.
And this is an execution layer, but it's also a settlement layer, right? So the way that you you're defining a settlement layer in Celestia is for, for example rollups that need somewhere that can interpret these fraud proofs or validity proofs and sort of settle what the actual state of the execution environment is. So on top of the data availability, the consensus layer, you have the execution layer that is also a settlement layer. And I suppose that the execution layer also encompasses rollups because a rollup is also in an execution environment.
So the execution environment has really two tiers to the settlement layer, but also the sort of, of rollup that all goes into the sort of execution layer. And then on top of that, you have applications like smart contracts that run inside a rollup, but the rollup itself can also have a token.
If we're going through from the top of the stack, is there going to be a dYdX application token that runs inside of a rollup that has a rollup token that runs inside of Evmos that has a settlement layer token that then uses Celestia as the data availability at the consensus and consensus layer that also has a token.
So there really like four different tokens going through there. And which ones of those do you see any value accrual, and how will value accrual happen at the Celestia layer? And also we need to discuss a little bit about fee congestion and where does congestion actually happen?
Does it happen in the execution environment or does it happen at the Celestia layer? Yeah, so, so the way I see it is that yes. There could very well be a token for every single layer. Like you might have a data availability token, you might have a settlement and you might have an app token. But now that might seem like a UX nightmare in theory, but in practice, it's not because the way that it would work is that like the end user only needs to be exposed to the top layer token, which by the way, it might not even meet the app token, but could be like a stable coin, like USDC. The app itself could accept payments in USDC and convert them to the app token like via a mechanism.
So if you have like the operators of the app chain, they accept payments in their app token, or they accept the app token for some service. but the app chain has to pay the settlement layer. So they can like they can do an exchange the app token for some settlement tokens, and then pay the settlement layer.
And then settlement layer like needs to pay the data availability layer using the same process. But this is effectively like how any supply chain works except that the fact there's different tokens. For example, Twitter pays its provider which pays his hardware providers and so on and so forth.
We do have John from Delphi here. John, go ahead. Ask a question. Yeah. So thank for giving me the chance to speak. So while we're talking about architecture here, there is the one issue that that I've been wondering actually.
So I want to get Celestia teams' opinion on this. Anyone feel free to step in. So, if we're talking in terms of the base layer, the Celestia layer, we know that there's data sampling light clients and, these light clients can effectively know how big the target size of the Celestia chain is. They know this by looking at the block header size. So they effectively have a discretion over how large Celestia block sizes are. So if we imagine these light clients are interested in a particular rollup on Celestia, for there to remain secure they would have to assume that there is a full node in this rollup that would hand them the validity and fraud proofs. So that becomes a point of in interest here is that do the light clients have any discretion over how large the rollup blocks can get?
Or can they enforce this somehow? because if we imagine a giant rollup that does a lot of execution, and that there's only a handful of full nodes that can actually execute them and hand over the fraud proofs. Then we're looking at a centralized execution layer on top of Celestia. So I was just wondering if there's any way for data availability sampling light clients to ensure the block size of the rollups that sits on top. Thanks.
So this ties into bit what I said earlier, which is that there's no way completely program to know how many nodes are on the network. Therefore having something programmatically entirely on chain to design a block size is probably not a good idea. And therefore, this is why we use off chain governance, similar to the most robust, decentralized blockchains like Bitcoin and Ethereum because it allows end users to have sovereignty over the blockchain, regardless of what the block proposals vote on, regardless of what even token holders vote on.
End users running nodes are the ones that ultimately control the rules of the chain through governance. So a single node on its own acting as an island, doesn't really have any control over the block size, but the community of node runners does, regardless of what the block producers or even token holders want - they can simply hard fork or software or whatever to change the rules so they can prevent block size increases that they don't want or suggestions to increase the block size that they don't want, or that they won't accept.
Well, rather in the first place that a hard fork maybe necessary for block size increase. Yes. Did that answer your question?
I think John's question was also about can rollup blocks have a block size limit and, and yes, they can. like a rollup application could also define like, say like add is rules that a rollup block can no longer be over a certain size.
We have another request for a question? Degen block, go for it. Hello guys. Thanks a lot. I hope you can hear me well. So first the discussion is super interesting, but I'm not super technical. so I'm not sure understood everything. The question I still had was the following. Everybody's talking about modularity now. So I wanted to know guys what you thought about the design of a Polkadot and could we consider the base layer of Polkadot a data availability layer? or is it something completely different? Thanks.
I mean, every layer one is kind of a availability layer. But I guess, what Polkadot does differently from Celestia is that parachains in Polkadot, the validators of the main chain of the layer one, they also execute part of the state of the parachains.
We have Brandon here. Brandon, please ask your question. Eric gave some really good context on what it might look like for Cosmo zones to opt in here and to solve some of the data availability challenges associated with sovereign zones. I think most people are pretty familiar that if you're running a rollup, you have to make some decisions about where you're going to store that state, whether that's on an L1 like Ethereum or like in the validium model where you're storing that with some sort of a data availability group. Can you speak just briefly on what it looks like to integrate a rollup or a zone with Celestia, such that it can guarantee that publishing of data has occurred.
Thanks, Brandon. Sure. I guess I can take it since no one else seems to be interjecting. So there's kind of two immediate approaches that one could use to have rollups, as we know, on Ethereum leverage the data availability guarantees of Celestia. One is what do we call the quantum gravity bridge.
So in in this design, you have a rollup, it operates on top of Ethereum. It does adjudication of proofs. So either validity, proofs or fraud proofs on Ethereum just as they do today and they can deposit and withdraw coins from a bridge contract on Ethereum. the distinction between a Celestia and a rollup on Ethereum as we know on love is that the data availability, instead of being posted to Ethereum is instead posted to Celestia.
And the immediate effect of this is that it would dramatically reduce the fees. At least in the short term, there's a bunch of caveats around long term fee markets, but that's like a multifaceted game and stuff. So we won't go there. But at least in the short term, the immediate effect is that it would significantly reduce free fees from several dollars to a fraction of the penny all while having very strong security guarantees because users can perform data availability, sampling.
To know that to know whether the data on the Celestia side is in fact available or not before deciding to use the Celestia the other immediate approach for people who want to leverage Celestia for data availability is some project that we've been calling Cevmos which is essentially an EVM settlement only layer that runs directly on top of Celestia.
And then you can build execution layer rollups on top of this. So you can, for instance, fork any up that exists on Ethereum or, if you want to do also a side chain, but you know, for the purposes of shared security, any, any rollup, so anything like Arbitrum or Optimism or Fuel or ZkSync or StarkWare, anything you want, you could just fork onto Cevmos cause it's EVM compatible.
So that's the thing that would verify the proofs since Celestia itself cannot verify proofs. And then Cevmos would then use Celestia for data availability. So these are the kind of two immediate configurations that we're seeing pop up with regards to rollup using with Celestia.
There is a third configuration that I think people are starting to get excited about, which is a sovereign rollup. So Cevmos is an example of sovereign rollup. It's a rollup chain that operates directly on top of Celestia, as opposed to requiring another blockchain to a due indicate its proofs.
That is the first example but is not the only sovereign rollup that can exist or that will exist. And I think there are some growing excite into the community to build out Celestia first sovereign rollups that do not rely on another blockchain to verify proofs that are hopefully going to be built and then not too distant in the future.
Does that answer your question? Can I, can I add one thing? go ahead. Think Brandon also mentioned, Brandon also mentioned how it would look like if a Cosmos zone, would, would be like turn into a rollup or would be built as a rollup. And I guess that ties in well into what you just said with the so in rollups, because you could build a Cosmos SDK chain, that uses what we have a project called Optimint that essentially is compatible as a drop in replacement for Tendermint.
You can build Cosmos SDK apps but instead of doing BFT consensus, it basically dumps the blocks onto Celestia. So that would give you Cosmos zones that are sovereign as a rollup, that's also just one example of these sovereign rollups.
Thanks, we have another question. Hey guys, thank you for taking my question. question on Cemvos as a settlement layer. So in theory, you would be able to have both EVM based rollups and CosmWasm based rollups settle on Cevmos. And would that induce any kind of special, interoperability between those two or, composability?
Mm, that's a very good question. I guess for a CosmWasm rollup, you'd rather go with the same model that John described before, where you have like a dedicated settlement layer for settlement and a rollup on top.
You, you can't settle CosmWasm directly on Cevmos because Cevmos is EVM based, not CosmWasm based. However, as Ismail said, you might want to create a different settlement layer that is CosmWasm based.
Like one thing I've always said before, it might make sense for the Cosmos Hub itself to implement and integrate Wasm into the hub and use it to support CosmWasm rollups. However, it might be possible to settle all rollups directly on EVM by compiling it to an intermediate language.
I think Arbitrum Nitro works similarly because it uses Wasm, but also like for example optimism has a fraud proving project called can which Cannon where arbitrary Go code can be compiled into MIPS code. So if you can compile any program to MIPS, you can effectively fraud proof that.
I mean the EVM based settlement layer. Thanks. We have another question from no excuses. Go for it. Yeah. I, when I was reading Vitalik’s blog post on security and that the future would be multi chain but not cross chain. He specifically called out Celestia in saying that consensus and data availability can't be delegated cross chain without sacrificing consistency and security guarantees.
And I wasn't aware of, I haven't seen any written rebuttal to that claim. So I'd be really interested in reading something about that. And then my second question is what's the place of Celestia or the value proposition or moat in a post shared security launch for cosmos? yeah.
So first the first question I agree, technically speaking with Vitalik, I mean, in fact I've said the exact same thing as Vitalik before in a blog post in October of last year, where about the multi chain ecosystem. Where we disagree is on the utility of what he calls chains of sovereignty or zones of sovereignty.
Because what he's effectively saying is that his argument is effectively that every chain should use the same settlement layer to have shared security. And it is not really useful to have different settlement layers because you can't do a trust minimized bridge between that. I've made the distinction between, this idea of a trust minimized bridge, which is what rollups are based in and what I call a committee based bridge, which is not trust minimized, because it relies on honest majority of a committee to operate that bridge.
I think like both have a place in the ecosystem. I think it is unrealistic that we will see a single zone of shared security. I think in practice we will see multiple sets of settlement layers or rollups that have committee based bridges with each other.
Because as John said earlier, there's lot of interest, like in our community of building what's called sovereign rollups, which are rollup that don't live on any settlement layer. And there are several reasons why you might want to do that, including more freedom and not having to be bounded by the social contract of settlement layer.
In terms of the second question, which is how does does Celestia compare to the kind of the cosmos interchange taking or shared security model? So the cosmos interchain staking model is very similar to Polkadot where effectively you can kind of pay or request the Cosmos hub validator set to also validate your chain.
But that's fundamentally not scalable because like all the validators have to execute all the transactions in your chain. So for example, in you have a limited number of execution slots, but rollup don't require that becaue rollups do off chain execution. So Zaki also agrees me on this, but the Cosmos interchain staking model is more kind of geared towards or more appropriate for the Cosmos hub, having chains underneath it, within the same kind of governance system. It's kind of like having subsidiary chains under the Cosmos hub, but it's not really kind of like a long term solution to shared security.
Okay, so we have time for one last question, and then we're going to go back to Eric for his closing thoughts. Alpha key, please.
Okay. So, I think what's kind of being recognized here is that the on-chain data costs are extremely expensive. And if you want to do data intensive things it's really expensive. I'm curious of your thoughts and realizations around splitting out the data availability layer.
So, the beauty of the modular blockchain paradigm is that by separating execution, they are doing just data availability and consensus, with execution at a higher layer. This means that you can get a much higher throughput of data availability, whether long term, this leads to lower fees or potentially higher fees because of network effects over the over that is up for debate.
But regardless you end up with a much higher throughput of data availability immediately, which to the effect of this is cheaper transactions for the foreseeable future. So that alone just separating these things, the modular blockchain paradigm allows us to build applications that are much more data heavy, such as rollups right. Because rollup on Ethereum today, you can see, just the on chain cost and then the order of a dollar or maybe $2, just the on chain cost. And that's what Ethereum's currently not too high transaction fees. And it hasn't been too high for the past couple of weeks. So this is just the on chain cost of data, a dollar or two.
And this is comparing to a few years ago when you, when people are saying is like the internet of money showed not cost more than 5 cents per transaction. And now we're looking at a dollar or two just for the on chain data cost, let alone the cost of execution and so on. So, the advent of the modular blockchain paradigm allows for data heavy applications to ideally run with substantial lower fees.
Thanks, John. So we're at the home stretch here and we'll go back to Eric. Eric, you once said to me thatCelestia is one of the few projects where I feel like even if I tried my hardest to destroy it, I probably couldn't. Can you expand on that more, or just tell us where you see things going and, and sort of your, your beliefs around Celestia and you can conclude your point of view as it relates to this topic and we'll segue off.
Yeah. I mean, I think, I think one of the main, main reasons why Celestia is very difficult to criticize it's extremely simple. It is doing more by doing less so by doing as little as possible. It births this whole modular blockchain stack by just focusing on one piece and doing one that one piece very, very well.
But throughout this conversation I've been trying to okay. But if I had to, like, what, what is the most annoying question that I can ask the Celestia team? Like what is the one thing that I can latch onto to, to mess with her heads a little bit.
So let's say in Ethereum for instance, we see that there are a couple of applications that are extremely used, like there there's an extreme demand for those applications and that we see Opensea and Uniswap impacts the fee environment for all other Ethereum users.
Let's imagine that something similar also happens in Celestia that you have two or three execution environments that end up just being extremely high demand for those. And they drive up the fee levels on the Celestia base layer. Would it possible to say here that Celestia is an extremely important piece of the modular blockchain thesis stack, but in itself it is a monolithic data availability layer because all the demand for Celestia impacts all of Celestia users.
The reason that I think that this is the best, most annoying question to ask, perhaps John here is that I know that John is a very loud critic of the avalanche project and avalanche. Their vision for scaling is basically using different subnets, which is like completely separating the ecosystem into separate environments.
John would you think that would make sense? If you have one Celestia layer and the fees go up to it turns out that it's very expensive to use Celestia for like micro payments use cases. Do you think that it makes sense to segregate even Celestia into different subnets so that once you have one Celestia them that is cannibalized of with usage then you sort of create another parallel Celestia.
That would be like a subnet for Celestia where you can have Celestia two where the fee environment could then go back to being low again. And then you can sort of scale the system by making and more subnets as demand is cannibalized on either of these systems. That's sort of the most annoying question that I could come up with for John.
Sure. I can take it since I've been called out, but I'm going to answer half of that and leave the other half to Mustafa. So the first half is that, yes, it's true that as demand grows there's a certain capacity of block space and maybe it becomes expensive. But a caveat here is that there's a number of things that we can do to make capacity grow in ways that traditional monolithic blockchains cannot.
The first is the scale out property of data availability sampling, which we've talked about a few times, Which is that the more users there are, the more you can increase the block size securely. The second thing is because of the fact that every block, some tiny amount of work done by the validator set management is stateful, but the rest of the block, which is the vast majority of the work is essentially stateless. It doesn't rely on any previous block existing. And not only that it's highly parallelizable because we split up each block into a square and perform operations on each row and each column of the square completely independently. So this leads to the potential for doing what we call internal sharding where rather than sharding across different identities within the network you essentially have a single validator but that can be split up its workload across multiple not as powerful worker computers.
So this allows you to essentially, I don't know if you'd call this horizontal scaling, but essentially allows you to just very easily produce very large blocks because you don't need one super computer. You can just spin up a cluster of very not so powerful computers and it it'll still work.
Now with regards to, even if we have these techniques, even if we have these mitigations can they reach a point where there's simply too much demand for the capacity of a single Celestia chain? And this is where Mustafa is probably better to answer because he actually wrote a post about this not too long ago.
Segue to Mustafa. Yeah. So as I said before, like no blockchain can guarantee cheap fees. The only thing a blockchain can guarantee is certain scalability properties and certain throughput properties. But it cannot guarantee like ultimately the fee market is a free market.
It's simply not possible for blockchain to guarantee cheap fees without conceding two things. The first of which is, is DOS resistance. And the second thing is the target hardware requirement for block producers. And this is kind of like an interesting debate.
People have said before, like Solana is centralized because it has very high block production requirements and very high requirements for users to verify the chain that he need 256 gigabytes of RAM. But then Vitalik recently put out a post which he called the endgame post, which is this idea where he kind of had this thought experiment, which said, asssuming that I had a blockchain that had a very high resource requirements to produce a block, how can I adjust that blockchain so that I'm comfortable with it? And the short answer to that is that to be comfortable with a blockchain like that need to allow end users to actually verify the correctness of that chain using technologies like data availability, sampling, or fraud proofs, or ZK proofs, which is what rollups use. Because those technologies allow end users to verify the state of the chain with very low resource requirements.
Even though the requirements for actual block production is very high. But then the question is like, how far do you want to take that end game? What is your limit for block production? And to what extent does that affect censorship resistance? Because in theory we could have an infinitely scalable data layer that reaches Google levels of scale.
And the question is like to what extent are we comfortable with that? Because maybe you want to have block production requirements that are not too high, so the threshold for someone else step in case someone senses the network is struggling is not that high.
That's the first thing. And the second thing is well censorship resistance. I know there are some ways to achieve censorship resistance. Even if you have a somewhat centralized block production. But the question still remains, to what extent or to what extreme do you want to take that? And if you don't want to take it to an extreme, then you do need multiple chains and multiple data available layers that do have different security guarantees and fragmented security.
Okay. We're coming on final comments. Eric was anything else you want to say before we go off? I just had a tiny last question, which was, I heard that, Evmos running on top of Celestia would limit its use cases to only allow arbitrating disputes in rollups.
So Evmos would only look at rollups and settle the fraud and the valid proofs. But the question that I had there was how do you actually limit that in practice without making the system permissioned? and what if someone wants to experiment with a new type of rollup and a new type of fraud proof? How do you enable that?
So, I mean, there's kind of two ways that we're looking at restricting Cevmos. the first way is what you mentioned, which is like you have a set of whitelist, smart contracts. So like that's the dumb way of doing it. So you just set your white list, like optimism, and only certain smart contracts can be deployed.
In theory if you want to experiment with a new kind of rollup, you can still do that. You just have to deploy it as an L3. Like you have to use L2 as a settlement layer and you have to deploy your rollup as an L3. So like it's still possible to experiments with different kinds of rollup or different types of types of contracts or layers.
But the second way that we're looking at it, which is kind of more interesting to us is just to adapt or adjust the resource pricing of the EVM to make it restricted such that it's not practical to use it for on chain applications, but only rollups. And the main way you would, we would do that is by increasing the gas cost for like state access, state rights and state reads such that there's a limited number.
You can't do more than a certain number of state reads and state rights per transaction. So if you want to do more than that, you're are forced to use a rollup, but that doesn't actually place any kind of limitations on what, on a contract, on the chain, just on the resource requirements that each contract has such that it is only practical to deploy, rollup based contracts on top of layer.