**A** (0:00):
Thank you guys. Everyone, my name is Sunny. I'm talking today about a concept called Mesh Security. You may have the title of the thing was the subtitle was why we don't need L1s. It was a little bit of a typo. It was actually meant to be why we don't need L2s, but hopefully that was a little bit more controversial and maybe get some more people to be interested in listening. So before I just jump in, I work on Osmosis. Osmosis is a chain in the Cosmos ecosystem. The Cosmos ecosystem looks a little something like this. It is a network of 50 plus interoperating chains. And we'll come back, and that's osmosis right there and the big purple one. But we'll come back to this in a bit. Before we start talking about blockchains or anything like that, I want to talk a little bit about political economy. So I'm sure everyone has seen at some point before the political compass. It, you know, puts things on this authoritarian libertarian axis. And then you have the economic left, the economic right, access. And I saw this like meme on Twitter like probably three plus years ago, and I just could never get it out of my head. It was putting network topologies on the political compass axis. And this just made so much sense to me where it's like, okay, you have this like, okay, what does authoritarian versus libertarian mean? Do you have like hierarchical centralization or decentralization? And then economic lefts are all. Are all nodes have like equal weight or is there like a hierarchical system? Are there power laws involved? And so, you know, when we're designing blockchains and decentralized technologies, I always love this quote from David Clark. It's we reject kings, presidents and voting. We believe in rough consensus and running code, right? We should be trying to avoid these red and blue systems and building for, you know, green and yellow systems instead. So. Well, we actually have some systems for now, green looks pretty cool, right? Like we should be working on that, right? Having decentralization, giving everything equal power. And so we've actually built systems for making these green things possible and what we call these things consensus protocols. And we have different types of consensus protocols in the world. We have like more technical consensus protocols like BFT consensus. You have social consensus protocols like democracy. The problem is these things work really great, but they don't scale very well. BFT Consensus protocol. It's this like highly complicated thing under the hood, not infinitely scalable democracy. When I mean democracy, I mean like true democracy where it's like every person, one vote. This is a picture from the Swiss canton of Oppenhollern which is every year, four times a year they do an open air democracy where everyone goes to the town square and raises their hands to vote. And one of the things with you know, because remember green consensus protocols need N squared communication. That's why these things are not infinitely scalable. The, the open air democracy is end square communication because it's using visible line of sight as the consent, as the communication mechanism.
**B** (3:21):
Right.
**A** (3:22):
But these are not scalable especially in blockchains today.
**B** (3:24):
Right.
**A** (3:25):
So we are inevitably living in a world that we need multiple chains in order to achieve what we're trying to do. Now the question that remains is how are these chains going to talk to each other, how are they going to communicate, how are they going to secure each other? And you know, and there's many people like building different types of potential topologies. I think one of the most popular topologies that's being pushed today is this very roll up centric view. This picture is from the Celestia, you know, docs and stuff. But I think it well represents what people are trying to build. But what we're just building here then is like meta red authoritarian systems, right? Where like systems, all the security and power and control lies in one central group or you know, which would be Ethereum or whatever the L1 that everything is getting its security from. Then you have this whole system of L3s that is being proposed like great, now we're building blue systems. Nice. You know, I think, you know we are building towards green and yellow systems, right. And there might be possible to build meta green systems as you can build like recursive Tendermint Tendermint over ibc. Sriram actually has a really good paper about this. I recommend checking it out. It's called like I forgot what it's called but you can check it out. But for us, you know, we think that the natural way the world actually works is via these yellow systems. And that's what we should be building towards. Building networks of, you know, non hierarchical systems where chains can communicate and talk to each other. And that is effectively what we've been building with Cosmos for the last five years. And it's actually at least at the communication level that's what we have live and working today. Now the question though remains one of the most common questions about Cosmos is how is security going to work? We have this network of 50 plus sovereign chains. How are these ever going to be secure enough? So that's what we're going to answer today. We'll talk a little bit about different models for economic shared security and the evolution of how it evolves. Right? So, so this is a key for how this diagram is meant to be read. These circles are validator sets. These hexagons are blockchains and the line between them says this validator set validates, provides security to this blockchain. So today the world we have is two sovereign chains, let's say Axelar and Osmosis. They have their own sovereign validator sets and they're both securing only themselves, right? There's no shared security going on at all. The first step that you would do is go towards this thing called replicated security. This is where you can have a chain like the Cosmos Hub, say, hey, you know, new chain that's launching. You don't need to have your own validator set. We will have our entire validator set. Secure your chain. You are getting the full security of the Cosmos Hub. And this is this ICS proposal that has been, that's being launched on the Cosmos Hub right now. This is not really that scalable, to be honest, because this is, if you think about it, it's really just a block size increase. It's not actually helping scale the system much. So the obvious next step towards this is, you know, sharded replicated security where you take a subset of the validator set and have them be the ones that secure this other chain, help provide security to it. And so, you know, you can imagine this actually starts to become more scalable. And so this idea, you know, we've been having this for the Cosmos Hub for, you know, many years and it's actually been adopted into Ethereum because this is basically the idea behind Eigenlayer today, right? Eigenlayer says, hey, we can take subsets of the Ethereum validator set and use that to provide security to new chains. Cool, this is really nice. But chains are gonna wanna have their own staking token as well, right? Whether it's for value capture, for incentive alignment. And so the natural thing what's gonna happen is really chains are going to want to have their own validator set, like, let's say Osmosis. We have Osmo as the staking token. We have our own validator set, but we can also tap into something like Eigen layer and borrow security from Ethereum as well. Kind of almost turning us somewhat into like an L2 of Ethereum, right? So you can have this and you can imagine that this will actually happen where you'll have systems with their own sovereign security, but they'll be augmented by something like Eigen layer. Cool. This is like a, you know, we're getting towards a little bit more sovereignty now, but you know, we're still living in this like very red world right now. And this is what I call like the empire and colonies view of the world, where you have one empire that is like the security provider for the entire system and the colonies have some level of sovereignty, but like they have, you know, no really ability to opt out and like there's no freedom of choice going on here. The world that we're trying to build for is a world of nation states.
**B** (8:22):
Right?
**A** (8:23):
Like sovereign nation states that are communicating with each other in a decentralized mesh format. So. Well, let's look at how security works in the real world of nation states.
**B** (8:34):
Right.
**A** (8:35):
What is the most popular, what is the most powerful security mechanism in the world? I would say it's probably the NATO alliance.
**B** (8:43):
Right.
**A** (8:43):
The NATO alliance is a network of many sovereign countries, each with their own military system. But they provide this shared security system where Article 5 of NATO says if anyone is attacked, they all rush to each other's defense.
**B** (9:00):
Right.
**A** (9:00):
It's each country, each sovereign state in the NATO alliance is getting the shared military power of the entire alliance. And, and that's what we need to do with blockchains as well. So. And you know, it is similar alliance based systems that basically provides the security mesh throughout the world. How do countries decide who to ally with?
**B** (9:21):
Right.
**A** (9:22):
Well, if you look at the NATO alliance, only four EU countries are not part of NATO. There is a deep intertwining between economic incentive like dependencies and desire for security. Dependencies.
**B** (9:38):
Right.
**A** (9:39):
And so you can look at something in blockchains, look at something like Axelar and osmosis on Axelar. I think like 60, 70% of Axelar's TVL is from osmosis. We're like the biggest customer of their bridge at the moment.
**B** (9:53):
Right.
**A** (9:53):
Meanwhile, four out of the top 10 assets on Osmosis are bridged via Axelar. These two chains have such deep economic interdependencies and it would suck for either of them if the other got attacked. And so the logical thing to do is we should be doing similar to the Eigen layer style restaking design. But both chains should be doing this and doing it bidirectionally. Right now you have a world where both the Axelar chain and the Osmosis chain have the combined economic security of their combined market caps. This is. And then you know, more chains will slowly start to enter this, this system as well. Mars is a, you know, lending app chain very deeply intertwined with Osmosis. It obviously makes sense to have these two chains sharing security with each other. And this doesn't stop you from tapping into other systems as well.
**B** (10:46):
Right?
**A** (10:46):
Like, you know, Osmosis can. While doing this mesh security system, we can also tap into something like Eigenlayer and get security from Ethereum. Or if you want, you know, you can also tap into something like Babylon gets security from Bitcoin. You know, Bitcoin Restaking is coming. Alpha leak, but okay, so how does restaking work? I don't want to go too deep into this because I think a lot of people are probably pretty familiar with Eigenlayer's design and it's actually almost identical.
**B** (11:15):
Right.
**A** (11:15):
The idea is that a delegator will go ahead and stake their OSMO on the osmosis chain. And what they do is normally when you stake on a chain, you are basically opting into being slashed for some slashing condition, right? You say, hey, I delegated my OSMO to the figment validator. I want my OSMO to be slashed if Figment does anything malicious. Okay, well, what's nice is then you can opt into additional slashing conditions. You can say, hey, if Figment does anything malicious on the Cosmos Hub blockchain, I also want my OSMO to be slashed. But what about a third chain like Juno where Figment isn't running a validator. The nice thing about this architecture is you can say, hey, I actually want to delegate to a different validator like Notional on the Juno chain. And even. And how it would work is if notional does anything malicious, they produce a toxic block, Byzantine block. Your Amelia's OSMO will get slashed on the osmosis chain. So that's a little bit of how restaking works. One of the cool things about mesh security is you can build systems where you don't want your chain to be fully controlled by any other one chain. You know, don't let any one counterparty chain get over 33% of your voting power. And you can set limits for this, right? So let's say something like Osmosis. We said, hey, we don't want Atom Restaking to ever make up more than 10% of our chains voting power. So what you can do is as more Adam gets restaked to osmosis, yes, you get the voting power keeps going up and up, but when it hits some cap, as more Adam gets restaked, it's still providing more economic security, but it doesn't get to a point where it has controlling levels of voting power on your chain. And this is really good. There's all ways of parameterizing this how you want to make it so you can set these caps. So a question that people often have is, you know, when, well, is this real or is this just an idea? Well, it is very real. There is actual code being developed for it today. You can go to the GitHub repo cosmwasm mesh security. You can see the live code. Here's an architecture diagram and the question obviously you're all thinking is, well, who's building this? How do I ape into this, right? Well, just like everything in Cosmos, we are approaching it from a mesh development standpoint as well. The there's no one company or entity that's building and funding this. There's a team of people from many different Cosmos projects are contributing towards development of this effort and funding is also coming from many different places. So the Osmosis grants program has coordinated a multi party funding system, getting funding from a bunch of different Cosmos chains to fund the development of Mesh security. So now going on to the other part of this. How does this compare with rollups, right? What makes this system different than, you know, the sovereign app chain thesis different than the roll up thesis, right? So looking at it from the modular stack perspective, you know, you have the execution settlement, data availability. I actually think the stack is actually incorrect. I think it really should be execution, data availability settlement. Because if you look at the flow of how things happen, first execution happens, then you need to prove data availability and only then can you do settlement. So this is kind of how it really works. We're going to ignore data availability for just a second, we'll come back to it and we're going to focus on execution and settlement. So in the L1, L2 model of the world, the claim is that all execution, execution happens on the L2 and settlement happens on the L1, right? And this makes sense for things that were created on L1, right? Let's say you have eth, you send eth to the L2, you can do stuff on the L2 with eth, but you want the settlement to finally happen on the L1. The thing is this doesn't make sense for a lot anything that was originally created on L2, right? Like the OP token, it was created on the optimism stack on the optimism chain and it has no value without the context of its execution environment. Or take something like a, a LP share of an AMM that exists on the L2. You can, yeah, you can say I want to settle that on L1, but that literally has no value. It is incomprehensible to the L1 because it doesn't make sense without the execution environment of the L2. So this whole notion that L1s need to act as the settlement layer for L2s is kind of nonsensical if you're thinking about it from perspective of state that was originally created on the L2. So our model of the world is say, okay, well every chain should be acting like the L1 for its internal state and an L2 for foreign state. What does that mean? It means that when you have two chains talking to each other using something like IBC today, every time a chain talks to each other in Cosmos, they are giving each other light client proofs. But that's not the end goal, right? We're going, we're going to go beyond that, right? The goal is that you should be giving full validity proofs. So the basically from the perspective of this top chain, it, it treats that the bottom chain is almost like an L2, right? Because it is getting these validity proofs and making sure that from its perspective it is following the rules that were set out for it. And so basically what happens is you share validity proofs bidirectionally between both chains and at time of communication you don't pause progress of each chain waiting for settlement and submission of validity proofs to another chain. This has all sorts of benefits. You remove any sort of liveness dependencies, right? If the L1 goes down, you can make progress on your L2 without waiting for the L1 to come back live. You decrease the latency of finality, you can reduce costs. And an important thing is you have no lock in into one settlement layer. And, and this avoids any sort of rent seeking, right? If your entire system settlement is based on inclusion on one chain, that one chain can then spike up costs that it takes you to settle on that chain and you have no alternatives.
**B** (17:31):
Right?
**A** (17:31):
The mesh design is how you avoid that by removing this lock in. How does data availability work in this world? Well, there's two ways of doing this, right? One is you can use a data availability provider like Celestia where you can say okay, a transaction is created on chain. Two, you post the data for it on something like celestia and the chain 1 validators are running light clients, data availability sampling light clients of Celestia and then you're able to send IBC packet Data. And as part of the, to accept the IBC packet data, the validators of Chain 1 have to approve that. Yeah, we are aware that the data is available on Celestia. The other model you can do is you can actually do something called mesh data availability, where you can actually remove Celestia from the system and say, hey, Chain two is running its own data availability sampling system. And the Chain one validators, if there's enough of an economic relationship and it's a popular trade route, the chain 1 validators can actually just go ahead and run data availability sampling like clients of Chain two directly, and they can accept IBC proofs directly. So now you don't have to rely on one centralized data availability provider. And I think both of these models will sort of coexist and depend on, you know, what sort of use cases are being used. One of the most popular thing, one of the cool things that you can do with L2s today is this idea of exit, like exit games and censorship resistance.
**B** (19:04):
Right.
**A** (19:05):
Where if the L2 is censoring you, you can submit transactions on the L1 that have to get included in the L2. How does, how would this, what is the analogy for this in the mesh security world is this idea we call interchange sanctions. So how interchange sanctions would work is imagine Amelia is trying to post a transaction on Osmosis, but you know, the osmosis chain is being malicious and is completely censoring her.
**B** (19:30):
Right.
**A** (19:30):
Well, what does she do? She can submit that same osmosis transaction as a priority IBC packet on the Axel, our chain. So one thing about how IBC works is you can have what we call unordered channels or ordered channels. This is a new type of channel that we're creating that allows for priority setting. And by setting a priority IBC packet, what that means is that the Axel, our chain, will block any IBC from. From osmosis until Amelia's transaction is processed on osmosis. And you can do this on other chains as well. Right. You can say, oh, on Juno I'm going to go ahead and submit this same osmosis transaction there as well. And now Juno is going to block any IBC traffic with osmosis until that transaction is processed. You effectively have interchange sanctions.
**B** (20:19):
Right.
**A** (20:20):
All of the rest of the Cosmos network is, or this interchange network is sensor is sanctioning osmosis until it stops the censorship. So this is sort of our equivalent for how we play these exit. We solve this like liveness exit games that you have in L2s today. So yeah. And once you do the proof of processing, it will unblock the channels again. So, yeah, I think I talked about a lot of different things. Feel free to. I know there's a lot of different things going all at once. Mesh data availability, mesh security interchange sanctions. If you have any questions about any of these, come. Feel free to talk to me. Jake Hartnell from Juno is also here. He's also one of the core contributors to mesh security. He can also help out as well, so thank you.