**A** (0:09):
All right, is everyone still awake? Barely. Okay. All right, so I assume most of you know who these people are, but quick introductions.
**B** (0:23):
Sure. Hey guys. My name is Sunny, one of the co founders of Osmosis. It is a Dex in the Cosmos ecosystem and I've been working in the Cosmos ecosystem for the last six years doing a bunch of different things.
**C** (0:39):
Hello, my name. Is it on? Oh, there you go. Hello everyone, I'm Mustafa. I'm one of the co founders at Celestia, which is a data availability layer that makes it possible to have to create shared security for rollups. And one of the things we're doing as well is we have a project called RollKit which allows you to deploy Cosmos chains as rollups on Celestia so that you could have a. So that Cosmos chains can have shared security.
**A** (1:06):
All right, thank you. I think this audience is pretty builder y, so I'm going to like, you know, just set the stage a little bit for where we're coming from for anyone who doesn't know. So, and then we'll get into some more juicy stuff. So Sunny, maybe do you want to start? You know, the original title of this was sort of app chains versus modularity, but I think, you know, there's a shift more towards mesh security modularity. Can you just like spend a minute steel manning an app chain thesis and maybe like why did you choose to make Osmosis an app chain to begin with?
**B** (1:41):
Yeah, so why did we choose to make Osmosis an app chain was we kind of realized that for the application that we wanted to build a lot of the things we needed to do, we needed to go change the core blockchain and like we just wouldn't have been able to do what we wanted to building on a smart contracting platform. Especially when you want to go do stuff around privacy or you know, mev resistance and like these are things where like privacy, you need to go change the cryptography of the blockchain. I don't have the ability to do that in Ethereum without engaging in like multi year long IP debates or you know, if I want to go change how the Mempool works, it's like, you know, I can't go do that on Ethereum while with an app chain I can go like touch all of these like core parts of the protocol without having to ask for permission from anyone and I can like make the blockchain. You know, Ethereum has to be credibly neutral or any generalized L1 has to be incredibly neutral towards the applications built on top of Osmosis does not need to be. It could be like, oh, we want to reserve a certain portion of our block space only for osmosis trades. We can do that. We want to be like any liquidity add transactions have to go before any trade. So you can't like rug liquidity before someone's trade. We can go do that. So, you know, it was all of these sorts of things where like building an app chain was the way to a fully vertically integrated stack gives the best features and UX that we wanted.
**A** (3:13):
To build makes sense. So in that vertically integrated stack, obviously you need validators. The model of validation is evolving rapidly within the Cosmos ecosystem. How would you define and like, you know, looking forward to contrasting it with Celestia and rollups and that security model. How would you describe the security model of osmosis in the context of its validator infrastructure, you know, interchange security, mesh security and how do you see that evolving?
**B** (3:44):
Yeah, so osmosis started off like every typical proof of stake chain where it was using, you know, it had its own native token called OSMO used in a proof of stake system similar to every Cosmos chain today. Then the next big change to osmosis security model came with this thing called superfluid staking which where we said, hey, beyond just osmo, why can't we actually use the DEFI assets built on top of the chain, most of which are backed by osmo have OSMO underlying them in the DEFI protocol in the proof of stake protocol itself? So what you could do, what we started with was LP share. So you could say if I have an OSMO atom LP share, you know, that has real OSMO underlying it, I can take the LP share itself itself and use it in the proof of stake protocol. And you know, the protocol is smart enough, it understands the LP shares. So it could be like, oh yeah, this LP share, we know it's worth roughly this much OSMO and we're going to provide this much of an additional discount risk factor on top of it. And so yeah, that's how that came about then, you know, that was, if you think about it, superfluid staking is sort of this like proto version of mesh security where mesh security, I assume most people here are pretty familiar with it. So I'm not going to go too much into it if I need to, let me know. But like it's this idea that hey, why can't we use other tokens as well as helping secure our chain? So things that we have these deep economic relationships with something like Axel from the axelar chain or Mars tokens from the Mars chain. Like, you know, these are things that we are very economically interdependent on. We should allow all of them to be also used to secure osmosis. So now it's like you can use base OSMO, or you can use defi assets on the osmosis chain, or you can use staked assets on other chains, all to contribute to osmosis economic security.
**A** (5:46):
All right, so here's a weird one. Is there any world in which osmosis would be an L3?
**B** (5:55):
I mean, we're not even in L2 yet. So what does it mean to be an. What does it mean to be an.
**A** (6:01):
L3, like an app chain on top of an L2 that gives you some degree of freedom to do design considerations like you were just describing, but not have its own validator set?
**B** (6:14):
Yeah, I mean, I think having like long term, we should be like all Cosmos SDK chains should be generating fraud or validity proofs.
**C** (6:24):
Right.
**B** (6:24):
I think rollkit is like actually making progress towards that. And so if the question is like, should we be generating these fraud proofs and using them in our communications with other chains, then the answer is yes. Should we get rid of a decentralized validator set? No, because we, our take is that like fraud and validity proofs gives you safety. Single sequencers still don't give you liveness guarantees or censorship resistance guarantees. And for those for liveness, you want some sort of decentralized validator set for censorship and resistance. Like the best solution that we know of is threshold decryption and it's in the name you need some threshold or over which to do the decryption over. And for that, a tendermint consensus protocol is a pretty good way of coordinating a threshold decryption protocol.
**A** (7:20):
Any comments on that, Mustafa?
**C** (7:22):
Okay, so now it's my turn. So let me stop from explaining what we're trying to achieve from the beginning. So the reason why we started Tedesia is because we saw that at the cosmos, you know, vision. It's a fantastic vision of having an interchange of like hundreds or potentially thousands or even millions of interconnected chains. And this was kind of like the antithesis to the original Ethereum scaling. Very bad. But at the time, which was just like one big chain that was sharded. Whereas this cosmos was like, okay, anyone can create their own chain. But the problem that we saw with that was that with IBC specifically, if you imagine a world where millions of chains, which is very feasible, like there's millions of websites. There could be millions of chains. We're very early. It's not feasible to rely on committee based assumptions for interchange bridging because you're fragmenting security across millions of chains. Right. And it's just not a very sound security assumption. So what? So ideally what we want to do with rollups is replace the committee basis assumption, right, with a fraud and OZK proofs and data availability sampling. And because you no longer need crypto economic assumption or committee based assumption for bridging, the roll ups can now have security without need, without any kind of like sort of big capital upfront cost. And specifically if those rollups all use the same data layer, they can all have a uniform level of shared security, right? So it's no longer like different chains have different levels of security. All the rollups have the same level of security because they inherit consensus and data consensus, an ordering from the, from the base layer. But that being said, I still, I also like think that it's a. I think people should also be free to create their own chains with their own validated set. I'm also not against that. And if people want to use mesh security, they can do that. I think it makes sense for some use cases and I think fraud proofs would make that even better.
**A** (9:41):
So that makes a lot of sense. I think there's definitely room for both right now, but I think we need to get a little bit into the distinction between those things and how they might, they might conflict. First, I want to talk about. I know you announced something recently, Sunny. The collaboration between Celestia and Osmosis. Do you want to say anything about that tia?
**B** (10:08):
Oh yeah. I mean it's not, you know, Osmosis is interested in being the interchange dex and you know, trying to provide interchain part of the modular stack is that like not everything needs, not every chain, not every rollup needs every service on top of it. Osmosis has the most developed DEFI ecosystem in the cosmos ecosystem. And like as more and more roll ups come on to Celestia, like you know, a lot of them focus on things like gaming like you know, the ARGUS stuff like you know, instead of them having to have their own AMMs and DEXes, like you know, we're working on a bunch of different toolings and things to make it so they can use Osmosis as their primary trading venue while still like keeping their roll ups like focused on their use cases. And then as part of that what we're doing is like making sure it's very easy to Bridge TIA onto the rest of these rollups. Right, because they need to pay for data availability and you know, having. I'm a strong believer in that. You need to have like protocol owned Treasuries paying for this core infrastructure rather than allowing dev teams and foundations to do that. You had the situation on Arbitrum a few months ago where like the dev team failed to pay the DA costs on Fund the Wallet on Ethereum that paid for the DA cost and like the chain came to a halt. Right. So instead you want systems where like, oh, maybe ARGUS could pay in its own native token. It'll swap for TIA on Osmosis and pay for the DA on Celestia. So yeah, we're basically just building up a lot of tooling to enable the transportation routes for TIA throughout the ecosystem.
**A** (11:52):
Very cool. So I want to talk a little bit about where these sort of models conflict and maybe under what circumstances is an honest majority of validators in your own validator set like better or worse than having a roll up and a different kind of like shared set of security assumptions? Right. So Chorus 1 recently put out this analysis where they showed that, you know, as validation becomes more expensive, as you secure more chains in an ICS kind of model, it might price out smaller validators or they'll cut corners and be just less good at it. You know, we end up with less security. What's your opinion on that?
**B** (12:35):
So I guess like my general take on this whole framing of rollups or versus mesh security as well is it's like there are. So like I said, rollups provide you proofs for certain types of things. Right. They can prove that like oh, the state transition function of your system was valid and you can prove that to something or someone at the end of the day you're still, you know, most of this idea of L2s and L3s and stuff, you're. You're proving it at the end of the day to some L1. Right. And at the end of the day that L1 is still secured by economic security and nothing else. Right. Ethereum, at the end of the day, its security model comes from economic security. It's not a roll up to anything else. Right. And so the goal of mesh security is how do we maximize the amount of economic security of system. So would Ethereum be better off secured by just eth or secured by ETH and the entire ecosystem of app like of defi assets built on top of it. Right. The same way Osmosis is more secure with superfluid staking than without superfluid staking, there's other things. You know, it doesn't only have to be for your base site settlement layer. It could be for things like your Oracle network, right? Like, you know, how do you generate validity ZK proofs for that? An Oracle is correct now, right? At the end of the day, Oracle networks are secured by economic security. Would you be happier with an E with an Oracle secured only by link token, or would you be happier with an Oracle network secured by link token and AAVE token and maker token and comp token? Like everyone who's using something should provide security for it. And you have this more resilient, decentralized economic backing for these like core parts of the protocols that can't be, you can't generate validity proofs for.
**A** (14:28):
And so Mustafa, in a world where sort of Celestia is at the bottom of that stack, what do you think are the forces that might act against that? That might select four roll ups instead of having that, that validator architecture?
**C** (14:43):
Yeah, sorry, my phone just off the top, but it's okay. Yeah, so I think, yeah, I think there's some important nuances like, yeah, it's true. Like base layers, like Celestial and eth, they rely on economic security for censorship, resistance, but not for state validity. Whereas like interchange IBC and presumably mesh security, they rely on economic security to prevent invalid state transitions. Not just for, not just for the sensitive resistance, right?
**B** (15:13):
No. So mesh security is just a protocol for people to add slashing conditions to actions, right? So it is implemented as an interface that you can write arbitrary slasher contracts for. The initial contract that we wrote is for tendermint consensus proofs. Fraud proofs.
**C** (15:31):
Right.
**B** (15:32):
But you, you know, we're going to write a dump like a contract for oracles, right? We'll be like, oh, here's this Oracle network. And like if you provide an Oracle update that's too far away from everyone else's, that is a slashing condition. So the idea of mess security framework is just a model for adding up economic securities. What you apply that economic security to is up to.
**C** (15:55):
But I guess, I guess, but for like the fraud proof stuff, you don't want to wait for a challenge period, right? You just want to slash.
**B** (16:03):
Yeah, that's up to the chain, right? Like, so some chains might say, oh, we want to wait a challenge fraud proof window before we accept IBC package. Let's say two rollkit chains, they might want to wait the fraud proof challenge window, right. For osmosis, you know, from our product perspective, like, you know One of the things people love about us is that you can deposit assets in a matter of seconds and increasing that to minutes or hours to accommodate these challenge proof windows. It's like yes, it is better from a security perspective, but unfortunately it just harms our product user experience that it's. We have to weigh those things against each other.
**C** (16:44):
Yeah, that makes sense. But I will also say that you can have a significantly shorter challenge period if you make the fraud proofs distributed peer to peer and not on chain. Because the main reason why Ethereum has a long challenge period is because you have to wait for the, for the, for to get to on chain. Or if you use UK proofs then you don't even need to do that. But I mean sure, like it makes sense for mesh security as a general model to add certain extra crypto economic security for certain, for certain slashing modules or slashing conditions. I guess just from my viewpoint I would say, I would see it depends on how many chains there are interchange long term. But what we're trying to achieve is a kind of a scenario where someone can just spin up a roll up chain in two seconds, bootstrap it without any crypto economic security. So kind of like we want to try and create a world where deploying a roll up chain as a roll up Cosmos chain, for example, is easier and more convenient in deploying a new smart contract. Like the same way that deploying a virtual machine on AWS is better and more convenient than using Squarespace to launch a website, for example.
**B** (18:01):
Yeah, so exactly. I think that the roll up model makes it very good. Making it as easy as possible to deploy a state machine is great. But where mesh security is coming in is like okay, most applications have other things they need to be correct other than just the state transition function. Right. If you have a shared sequencer system or some sequencer system, you want some economic security guarantees around your censorship resistance mechanism.
**C** (18:33):
So yeah, I mean it's definitely a true that a lot of roll ups these days aren't very, very sensitive resistant. But it's also like some important nuances there because a lot of people think that you need a decentralized. Some people think okay, well you're basically reinventing blockchains by having by needing decentralized sequence set for roll ups. But there's various designs that don't really require decentralized sequencer set. For example, like there's this thing called base roll ups where you're basically post like there's no sequence at all. You're just using whatever you're using whatever the blocks, however the blocks are ordered on the base layer. So you're using the base layer for sequencing. That does leak a maybe to the base layer, but ultimately ultimate goal. Even if you have a centralized sequencer, you can still inherit security from the base layer by having a way to force inclusion of transactions.
**B** (19:26):
Yeah.
**C** (19:28):
About that being said, I'm not against mesh security being used. I can also see models where rollups can have a decentralized sequencer set and a lot against mesh security being used to add bonding, add some kind of bond to become a sequencer in the sequencing set. Especially if that roll up doesn't want to have a token yet.
**B** (19:52):
Yeah, exactly. And yeah, the force inclusion stuff I think works. It is a little bit slower. Right. Like it's not. And then the base roll ups I think work. So base roll ups for anyone who's not familiar is the idea that like, oh, instead of submitting transactions to the sequencer, you instead submit, you use your DA layer as your sequencer as well. So you submit transactions directly to Celestia. And the job of the sequencers or state machines is to like read the transactions from the DA layer directly and like construct the blocks on top of that. Which I think works for some use cases. It's as you get more advanced in your use cases, like the kinds of stuff that we invented ABCI for, like it becomes more complicated. Like you might want to say that like, oh, here's certain types of transactions that we submitted encrypted, but our validators are using vote extensions to, you know, provide price Oracle data. But we don't want these things to be decrypted unless the price Oracle data has come in. Right. And so once you get into these like complex workflows, it like it really, the base roll using a base roll up which is not fully programmable becomes kind of harder and you want, at that point you kind of just do want your own decentralized sequencer system.
**C** (21:14):
Yeah, I guess like with the threshold mempool stuff that's kind of for censorship resistance as well, right? Yeah, I mean there's definitely trade offs between having either a base roll up, a centralized sequencer or decentralized sequencing.
**B** (21:25):
It's more about programmatic decryption where it's like, oh, I only want this decrypted in these scenarios.
**C** (21:32):
Right? Yeah, I mean there's definitely trade offs between and it definitely makes sense in many use cases to have a decentralized sequencer set, especially if you want better guarantees around the threshold decryption and also other things like more trust, minimized soft finality guarantees.
**A** (21:53):
So let's push into that a little bit. So you know, one of the criticisms slash like, you know, if you're a dev deciding how to architect your platform, one of the things you're thinking about is actually cost, right? So there's some criticism that having your own validator set costs a lot. You have to have emissions over time, et cetera. You know, within the roll up model, in the modular model sounds like there are a lot, you know, there's an increasing number of things you have to pay for, right? You have to pay for potentially sequencing, you have to pay for da. You know, maybe there are other things that we don't even know about that you're going to have to pay for. As things become more modular. Are there any sort of first principles arguments you can make about which one is going to be cheaper over time?
**B** (22:36):
It's, I think there's like different types of costs that exist, right? Like something like da. I think there's a pretty strong argument that there's like economies of scale to it because of like how like the encoding in Celestia works. Like the more data that you get, it's actually, it's better to have there are economies of scale of having one DA like layer that does the Reed Solomon encoding versus like many separated ones. Right. The other one though as well is like just on like engineering costs, right? Like Osmosis took the like some, some chains in Cosmos decided to build their own bridges, right? Like Injective has their own bridge to Ethereum or you know, SIF chain built their own bridge to Ethereum. For us, you know, we took this, we took the take that like building bridges is hard and a lot of like, you know, from the security perspective and engineering perspective and we just don't want to do that and we would rather work with a team and basically outsource it to them. Right. And so that's the other thing that you also have to think about.
**C** (23:39):
They didn't you tweet once something like, as an Asian, I don't like to rent. What was it?
**B** (23:48):
This was Leland's tweet. I think he's like, yeah, something about that. It's like the entire Cosmos thesis comes down to I don't want to pay for stuff or something.
**A** (24:01):
So in the Celestia model, do you have an opinion or is the stack itself opinionated about how those costs are structured? Have you thought about that in your design?
**C** (24:14):
Yeah, I mean the way to use analogy the way I would compare it is launching your own Cosmos chain is like having your own physical server and maintaining your like buying a physical server, co locating in the data center and maintaining that. Whereas like using rollups is kind of like just using AWS on the cloud. The server has higher upfront capital costs and you need like higher potential labor costs. You need like someone to maintain it. Whereas like the cloud it might be more expensive on a. Not even necessarily more expensive, but like certain scale. If you're like a big corporation, it might be more expensive, but for most people it's cheaper. And also there's less upfront cost. You're just pay as you go. So that's kind of the way I would compare it there. But from a session's perspective, all you have to pay from Sylvester is the data and that's pretty much it. You're paying per byte. It's like it's pay as you go.
**A** (25:19):
Makes sense. So I guess Mustafa, can you say a little bit about the validator architecture that Celestia has chosen? Right, and I'm trying to relate this back to what we were talking about before in sort of chorus one's analysis of, you know, the more things that you're validating, the higher the cost and you know that, that potentially being a centralizing force. So say I'm a validator on Celestia and say, you know, I've already developed this specialized infrastructure to provide da, right, that's optimized for that. Maybe I also provide Eigen da, maybe I do, you know, polygons, da, et cetera. Are you concerned at all about that becoming a centralizing force in validator architecture? And how have you thought about that?
**C** (26:06):
Yeah, I mean centralization in block production and validate infrastructure is kind of like a huge general problem in blockchains. I don't really know if anyone's truly really managed to solve it on a long term perspective. To me, proof of stake is basically flawed due to liquid staking. At least the current iterations of proof of stake. Liquid staking kind of creates natural monopolies. But the way I see it is that the end game is we want to try and we want to try to create systems where the end user can verify the correctness of the chain, even if block production is centralized. But using proof based systems like fault proofs and have like ZK proofs, you don't have to trust the validator.
**A** (26:54):
For.
**C** (26:54):
The correctness of the state validity of the chain. In some cases you might have to trust them for censorship, resistance. But there's various ways of kind of like trying to have increased message resistance in the presence of a centralized validated set. You know, things like proposed a block separation auction models and also threshold mempool encryption.
**A** (27:15):
All right, you got 90 seconds each. What's your most outrageous prediction for how blockchain architecture is going to change in the next two years?
**C** (27:26):
I mean, I don't, I hope this isn't outrageous because this is Nebula Summit, but I think there's going to be like millions of chains, you know, in a few years time. We want to make deploying app chains easier than deploying a smart contract.
**A** (27:41):
Sorry.
**B** (27:46):
Is this something I think will happen or what I want to happen?
**A** (27:50):
Either one, but whatever would be most exciting.
**B** (27:55):
I think we move away from proof of stake entirely and we move towards new sorts of civil resistance systems. I'm a big fan of reputation like web of trust based consensus protocols. And I think proof of stake had a lot of superiorities over proof of work, which is why I spent years working on it. But I think it has flaws and I think that there is a world where we can build better things than proof of stake. And so I'd like to, I would hope that like five years from now that our primary blockchains are not running on proof of stake, but are rather running on these like web of trust based consensus protocols.
**A** (28:35):
Do you think, how about like proof.
**C** (28:36):
Of personhood using worldcoin, Proof of orb, maybe less.
**B** (28:42):
I guess like what I'm looking for is something that, like decentralized identity systems that not using worldcoin but like using, using a web of trust to get some sort of pseudo identity system.
**C** (28:53):
Yeah, I guess there was some sort of proof of personhood or some type of proof of personhood of mechanism in some way.
**A** (29:00):
Do you think we ever connect back to bitcoin?
**B** (29:03):
Oh yeah. I mean this is why Babylon exists, right? Like, I think that, you know, another hot take which I think is probably true is a lot of cosmos ecosystem chains are going to be secured by bitcoin recently staking.
**A** (29:16):
Cool. All right, super interesting guys. Thank you very much. Thank you, appreciate it.