Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Marko Baricevic: Cosmos SDK - The Internet of Appchains

Episode Date: August 25, 2023

From the very beginning, Cosmos set out to provide an alternative to the monolithic blockchain architecture proposed by Ethereum. Cosmos SDK was the cornerstone of this vision, as it allowed developers to spin up blockchains effortlessly. Its modularity enabled custom, self-sovereign chains to become a reality. And, instead of being a jack of all trades, those chains were centred around a sole purpose, thus transforming them into appchains. In turn, as the ecosystem grew, appchains had to be interoperable with one another, but this was already a core feature of Cosmos, via IBC. Before Ethereum’s rollup-centric roadmap, appchains were thought to be a much-needed scaling solution. However, with the advancements of zero knowledge technology, the Cosmos SDK now faces another set of challenges as it navigates the market demand for L2 scaling solutions.We were joined by Marko Baricevic, Cosmos SDK product lead, to discuss the development philosophy behind the Cosmos Hub and how appchains evolved over time.Topics covered in this episode:Marko’s backgroundCosmos SDK’s history and high-level overviewCosmos SDK modules and VMsEthereum’s & Cosmos’ development philosophiesCosmos SDK value prop and use casesCosmos SDK vs. other frameworks (e.g. Substrate)Token value accrual and the fragmentation dilemmaUsing the Cosmos SDK to build rollupsCosmos SDK vs. Avalanche’s HyperSDKAdoption of fraud proofs and validity proofs by the Cosmos SDKEpisode links:Marko Baricevic on TwitterCosmos on TwitterCosmos SDK on TwitterInterchain Foundation on TwitterBinary Builders on TwitterThis episode is hosted by Meher Roy & Felix Lutsch. Show notes and listening options: epicenter.tv/510

Welcome to Epicenter, the show which talks about the technologies, projects, and people driving decentralization and the blockchain revolution. I'm Felix and I'm here with Meheroy. Today we're speaking with Marco Berichevich, who is the product lead of the Cosmos SDK. The Cosmos SDK is a framework to build application-specific blockchains in the cosmos ecosystem. I'm Marco, and welcome to Epicenter. Hey, thanks for having me. It's definitely an honor being on the show that I've been listening to for so many years. Yeah, we're super glad to have you as, like, you.

like such a long-term contributor to the cosmos ecosystem and beyond. So yeah, we're very excited to hear today about the cosmos ecosystem. But as usual, we get started a little bit with your background in crypto and how you get started and what brought you to where you are today. Yeah. I had a bit of a different entrance into crypto. Actually, like during the 2017 ICO boom, a bunch of friends of mine were making a bunch of money. And before that, I read about Bitcoin, but never got fully into it.

They were making a bunch of money. And for some reason, for me, I wasn't like, oh, I'm going to go make a bunch of money. I was like, I want to learn how this stuff works and why it is, why it is decentralized. And around that time is when I started to, I really dive deep into learning how to code. And then soon after that, I joined a enterprise blockchain company. And that was a lot of fun. We were using quorum from JP Morgan and writing a lot of smart contracts, writing a lot of tooling around that had a couple fun projects.

I find that consultancies are a lot like hackathons. Every two, three months you have to develop a product, and they just give you the specs of the product, and you just have to write code. So it was a lot of fun, learned a lot. And then I ran across one of the senior engineers at the Enterprise Consultancy showed me a video of Ethan Buckman and Jake Kwan talking about the tendermint and the Cosmos SDK.

at a Bitcoin meetup in like SF. And I just remember becoming so enamored by it. And I was just like, I don't care where in the world this is. I just want to work with these people. And then a couple months later, I found out that they're actually, they have a team based in Berlin. And so I applied. And then it took a bit of persistence. And four months later, I joined All In Bits or Tendermint Inc. and the rest of history I started out as developer relations engineer and worked as an engineer on Tenderman for two years and then came back up to the Cosmosis.

Right, yeah, awesome. So this is like you getting started. What year is this? I joined 2019, so like two months after the Hub launch. After the Cosmos Hub launch. And then I guess, yeah, now you're, you've like familiarized several Tenderman in and you started to work on the Cosmos SDK, which we're here to talk about today.

And maybe for the listeners, right, like you can explain a little bit on a very high level what the Cosmos SDK is and maybe how it has moved through the history. Since I think it's right, it's probably like the most integral part of Cosmos ecosystem in some way, right? So it really helps to get some context. The Cosmos SDK, like Tendermint, has had a few teams working on it. The Cosmos Ssts SstK, I think, were on the third team. So initially it was written by the team at All InBits, which included Alex Bez, Rigel, Aditya, Dave, Sunny, Jack, Sampling, Saki.

Like, they were all involved. But back then it was a lot different than it is today. Like, it was kind of all there was back then was forking Bitcoin, forking debt, and then early days of substrate and the cause was SAC. And that was really it. There wasn't much out there in the ecosystem. so there wasn't much user feedback. And then when Cosmos went through what we described as like Gore 2020, the great organizational restructuring,

we kind of like shifted and moved into a new team, region network, and they became the sole owners and maintainers of the Cosmos SDK. And they led it for about two to three years. And then I came into kind of a bit like the Cosmos SDK has this thing of, it's very hard to hire a project manager because you get, burned out really fast because you have to deal with an entire ecosystem of people complaining, people asking for features, people wanting different designs. And it's just constantly like a feedback

loop now, more so than it was before. But not only that is you have to also keep up with what's going on in the wider blockchain ecosystem. So it's like a certain balance to strike. And there's a few people that attempted and then kind of just gave up. It was just too much work and too much overhead and too much craziness. I like to attribute my not being able to be burnt out to Zaki and Jack just because they also just like constantly work. And so I learned that from them. But yeah, so came into the Cosmos SDCs, started leading it alongside region.

And then this year, the entire like maintenance of the Cosmos SstK shipped it to a new entity, binary builders, which the core focus of that entity is. the Cosmos SDK and the Builders program, the Energy and Builders program. So I guess maybe we can, you know, get into like what is the Cosmos SDK as well? So, I guess most people are familiar with the notion of, like, smart contracts, right, and Ethereum and you're building your application,

you're building a smart contract. Now, Cosmos SDK is essentially the first, or like one of the first, like, frameworks to build application-specific blockchains. And that's become, like, much more popular. nowadays, this sort of paradigm, which we'll also get into. But I guess at the start, maybe we can just dive into why is that, right? What's the benefit over having your own cosmos chain in this case over like just

writing a smart contract? So, I mean, there's always this like dilemma of the single computer to rule the world where we all have to share computation versus like owning your own computation and then maybe posting data on this one world computer. And so the app chain vision came from the need that, hey, like we, well, first of all, the Cosmos SDK kind of came from like, hey, we're building the Cosmos Sub. And we have this vision of app chains. And what better is it to like develop a software development kit, an SDK to allow people

to build app chains. And this became, this was kind of like the early on vision. and the Cosmos S-DK, okay, now you can control your own computation. You can do a lot more things than you could in the Ethereum space or in other spaces because you control, you have a lot more granular control over your gas, your computation, and over your logic as well. And so this really fed into, oh, like we can really develop what we want to not be limited. And this is like when we had the like Cosmos summer, I believe it was like last summer or two summers ago.

then we saw a lot of application specific chains coming up to Cosmos and kind of like really honing in on specific use cases for the application blockchain. Then I would say like people started discovering that like hey, it's actually a lot harder to get product market fit because everyone like in crypto we have this like craze of like VCs come in. There's a lot of money. You launch a token. Okay, now you have runway. Now you have X amount of yours to figure out your product market fit. And a lot of people were kind of like, going with that, then I think not only in cosmos, but in the wider ecosystem. And then it all of a sudden shifted to like, okay, now we have to go.

Now, I believe that we are going into a world where we have to have PMF before you launch your chain. Otherwise, it's just going to be kind of an empty chain, no blocks and so on. But today it's like the SDK really, like the sole purpose that by default it is able to do is like a application of blockchain, application specific blockchain. And for this, like, everyone thinks that Cosmos Sesticated is like, this is all what you can do. But we are kind of like shifting into the roll up space. And it's like kind of a like, why would we want to like shift away from blockchains into the roll up space?

Well, it's like if you look at deploying a smart contract, like a smart contract is an amazing way to really go to market really fast and search for your product market fits. And it's very easy. You can deploy different ecosystems. You can partner with these ecosystems and so on. And then, like, if we put that on a scale of zero through 10, let's say smart contracts are the easiest. It's like a zero. You can deploy it the same day, launch your product, and you don't have to worry about inflation, validators, and so on.

And let's say deploying your own blockchain is like eight to 10 because you have to now control a binary. You have to control your validator set. You have to work with them. You have to claim centralization. You have to work through governance and all these things. it is very difficult. It's not an easy endeavor to take on. And we have been fortunate enough that a lot of people in cosmos have taken this endeavor on and learned and we've been able to

take that knowledge and give it to newcomers. But the problem is like what is that in between? And that in between, I'm kind of coming to the conclusion that it's kind of the roll-ups. So you have like the 246-8 of the roll-ups from decentralized to shared sequencing to decentralized sequencing. that kind of like fills up. So it's like now all of a sudden it's like you deploy a smart contract, you're gaining a bit more adoption, but you don't know if you want to invest

all this money into developing your own chain and doing a whole migration. So let's do a centralized roll-up if you don't need the decentralization part. And then you start wanting to expand your product. Then you go into the decentralized sequencing. And then all of a sudden you're like, okay, wait, actually like we are seeing

that we're paying a lot of fees to these different protocols for data availability and settlement, now it's time that like, okay, we own this for ourselves because our token may have a lot of value, a large market cap, and so then let's go to our own chain. And so I'm kind of seeing that as the direction that people are starting to go, and I think DYDX is kind of the perfect example of that.

That's really interesting. Do you think that if the future customer journey is going to look more like DYDX, started off a smart contract on Ethereum, then went to an L2 or a roll-up, in this case, start net. And then the third step to come in a couple of months maybe is their own Cosmos chain. Do you think there's a risk that the Cosmos SDK is developing the application chain development framework, but it doesn't really have like a roll-up development framework and ecosystem today, that by default, people will go and develop in the, the roll-ups with the

Ethereum stack. And then jumping from a roll-up working on the Ethereum stack to Cosmos SDK will just prove so much of a big software development challenge that nobody will actually go into the Cosmos SDK stack in the future at all, but rather some other stack will. Yeah. So in this sense, we are like shifting a bit. So the idea, so we're working very closely with the roll kit team from Celestia and teams like dimension. And the goal there is that in the ideal world, so now we're doing some refactors of the core layer.

In an ideal world, the user will potentially, let's say a user developed smart contract on Ethereum. Now they want to still settle and do DA on Ethereum. they can use RoK with SCK, let's say with Polaris or Etherment, and then they just migrate their contracts. They have the same UX and the users don't know there's a difference. And then in the future, the goal is that they can swap Gookit out for Comet or a different consensus engine and then the actual state machine will be able to stay the same. And so this is kind of the direction we're going with the user journey we're trying to create.

And so, yeah, we're working. We were just talking before the call, but we were just talking about fraud proofs and validity proofs and how, like, Cosmos plans to take advantage, enter into that world. And so we're working quite closely with the Celestia and the RoaldKit team in order to really dive into fraud proofs, first of all, and then later on validity proofs.

That's what we're also. And I think we're going to go much back into it. I think maybe we can take it a step back also, because most people that listen to this probably don't really have a good view of how the Cosmos SDK is structured. So maybe we can talk a little bit about, you know, like one of the core concepts in my view, right, in the Cosmos SDK is this idea of the modules, right? You have like these sort of swappable features that you can kind of plug in to your chain or you build a new module that kind of can be used by the rest of the Cosmos SDK. So can you talk a little bit about that? what sort of modules are there

more on this switching builds? So like the SDK and the direction that we've been trying to articulated to users and new users coming in is it is a separation between the kernel space and the user space. And when I say the kernel space, this is like where the modules live.

And so the thing why we consider it the kernel space is because you can handle a lot more computation at this level. The gas functionality is a lot more freeing and it's not limiting like you would have in a virtual machine. And so some of the modules are like staking governance bank, some like authorization modules. You have slashing, minting distribution, kind of like these basic things. And these things,

they do and they do go by themselves in terms of like they don't need external intervention to mint a bunch of tokens and everything. So they do handle a bit more computer. computation. And so when users come to the Cosmoose SDK, it's like, hey, like a lot of users are using VMs and we're totally fine with that. Then we encourage people to use VMs, especially if they're going into permissionless environment, that they just want users to deplore like Juno and EMS and others. But like the kernel space is really where the application has the most performance, but also has the ability to do a lot more computation for the function they maybe want to do from the VM.

So maybe the VM calls into the user space. So the VM calls into the kernel space, the modules, and then they are able to do a lot more, a lot more things there. So what can you like expand on like what some of these things might be? I think like some of the things that like a VM would be limited by. So like within a VM, it's like you are gas metered. So you do consume gas on every functionality, all the functionality, all the business logic.

And so then you don't want users to do a lot because it is potentially a permissionless environment. And so allowing people to have kind of unlimited computation is a DOS vector. And so within the modules, within the kernel space, like that's more of the application developer needs to, they need to propose and upgrade. And then the update needs to be adopted by validators. And so it's a lot more of a involved process. And so here, the computation is only around I.O. Around the disk. And so once you're doing computation, like let's say if you're doing some proving capabilities

or if you're doing some bridging technology, within a VM, you have to do gas metering on the actual computation of the proving, of the hashing and so on. while within the Cosmos S Sst K, within the kernel space, that is a lot more freeing. And so you can do it, and then that won't affect your entire block gas consumption. And a lot of people may think that, like, oh, this is a dot specter. But if it does end up in some sort of chain of the chain slowing down, then it is actually the application chain, it was application developers fault because they did this premeditated computation in their chain before and it wasn't like an end user just like causing this a lot causing this amount of computation

to slow down the chain right i think one example here actually i guess is sort of this reward distribution on osmosis right where it actually like we have these epochs and then at the boundary you need to compute a lot where the LP rewards go to and this for example can slow down the chain just so we have an example exactly like uh the interesting thing there is um So there is like this thing in the causal test decay called begin block and end block. And what these really signify is at the beginning of every block, beginning of every block before the computation, before the state machine executes the transactions, what computation do you want to run before that? And then an end block does the same thing just after the execution of the transactions. And so within this, like in the osmosis case, they are doing a lot of computation for the LPs of the pools.

And so that is like causing a lot of, causing the chain, the state machine to kind of slow down a bit. But this is known. It's like as more users come in, it's just like, I think it's maybe like 10 minutes or less now, that the chain kind of just like stops. Everyone is doing computation. And then once everyone's done with computation, it continues as normal. Is it correct to think of it like this? And you look at Ethereum, in Ethereum,

So with any chain, there's kind of like core logic that you need to run the chain itself. And then there is kind of customizable logic that people can put for their own use case. And the chain goes live, which are like smart contracts. In Ethereum, Ethereum has this philosophy that, so when you think of like the core logic you need to run any chain, Well, maybe like an example is kind of like the staking system, right? How do validators get spun up? How does the chain get spun up? How do validators get torn down?

How does slashing happen? How does the native token of the chain? In the case of Ethereum, it's an ether, the case of osmos is the osmo token. How is that represented? What is the code that kind of handles that token? So there are all of these kind of like core functions, the native token staking, slashing, maybe something around governance that any chain needs. And then there are kind of customizable pieces where when you launch the chain in the first time,

you have the core functionality. You don't even know what kind of customable functionality the market is going to demand. So you want a way by which people can put their customizable logic on the chain. and that's in the form of smart contracts everywhere. In Ethereum, kind of the philosophy is that the Ethereum developers want to put all of this core logic of the blockchain as smart contract.

So in Ethereum, like the staking is handled as a staking smart contract. So when you are actually staking on Ethereum, you are sending a transaction into an Ethereum smart contract, written in Solidity, audited in that language. and then staking is a core functionality of the chain, but it is handled as a smart contract. So Ethereum makes that an explicit choice that even the core function,

like more and more of the core functionality of the chain should be written as smart contracts and go in that direction in the future. Whereas in the cosmos SDK, the kind of philosophies, let's separate out the two. So there is, let's call one thing like the kernel space where the assumption is that,

this will handle core functionality of the smart contract. What does it mean when staking, slashing, native token, bridging to other chains, maybe in the future generating zero knowledge proves, maybe producing hash functions, producing hashes. These are core things that the chain needs. Let's keep this in a kernel module. Let's kind of enable the developer of the chain to be able to sort of optimize these core modules for their use case. and then on each of these cosmos chains there can be

also the customizable side which is a VM that's running on the chain and the VM can be of two or four different designs and sort of like the VM becomes kind of like this user space and the VM at the core can seamlessly interact with each other and it's kind of like a almost like a philosophical difference on on how to do development between

Ethereum and the cosmos ecosystem. Yeah, I'd say like the biggest difference is like the Cosmos SDK is a software development kit, less so framework. And so while we think that it's like, it's very powerful to write things in native code, and so you don't have this like performance potential overhead bottleneck of writing it in the VM and the smart contract layer that

doesn't need to be done by everyone. And there are users of the Cosmos SDK who do write core functionality within VMs and then just pass it down to the SDK. And so we do the goal of the SDK is to be less subcomminated than other frameworks. So it's like, hey, like this is the Ethereum way. You can do it that way if you want. Like if you pull Etherment or Polaris into it, you can write everything in Solidity. You can take the same code from Ethereum and put it in, call staking functions.

All you need to do is like return, like the validator set, update and stuff like that. You can do that all from the VM. It's just you're going to have some performance overhead instead of just doing your with native code. But yeah, I'd say like that's the key differentiator. And I really love honing in on that just because, Everyone does think of kind of like, same thing with like IBC, SDK and like Comet. They are all are like SDKs and less so frameworks. And if they're not today, then like they're all going in the direction of more of an SDK than a framework or an easier term like a library.

So people can compose their application without being forced to do it the single way. Right. So really it's like more flexible and not dictating so much how to do it. Do you foresee like some of the teams or like someone else to build like a more opinionated framework on top of the sort of more flexible cosmos SDK? So like maybe people could reuse, you know, what Etherman, how they build their chain and that's like another sort of framework on top of the core flexible cosmos system. Exactly.

So the downside of this approach is that it becomes, it has the potential to become like many levels of frameworks, many levels of libraries that people compose. And so, like, I'm talking with Polaris and Etherment, they have this like EVM on top, and they're both going in drastically different approaches. Polaris is kind of like they're developing a separate process that is kind of like a library that can be plugged into many different frameworks or many different SDKs. Etherment is a bit more tightly coupled to the SDK, but they still have things that you can add on, features, plugins and stuff like that.

And so that is like a downside that it's like once you go too modular, then people generally don't know which direction to go because it's too freeing. And this is, this definitely is something that I've like seen with other SDKs and frameworks in the blockchain ecosystem that it's like they're so unopinionated that it becomes harder to use because it's harder to find examples just because everyone does it so differently. And so we're trying to be mindful of that when we're doing, when we're kind of reshaping the Cosmos SDK in order to take advantage of these new worlds that are emerging like roll-ups. Maybe before we go into roll-ups, like we could go into, in your experience, what have

been the unique setting points of the Cosmos SDK and what are kind of like some of the success stories it has had in the past? The Cosmos S-DK has, because it's been around, for so long. It does have a wide range of users. So the Binance chain, the B&B chain is used with the, is built with Cosmosterscate. The new Greenfield project from Binance is also using the CosmosisdK. There's going to be Celestia, D-Y-D-X, wormhole. Kind of the list is kind of ongoing. And there's a lot of users that we also don't know about. We have a lot of enterprise users that kind of hide that their enterprise and come and ask questions, and then we help them.

And then after they ask to sign an NDA or some contract, then we discover that it's like some enterprise using the Cosmos SDC. So there's definitely been a wide range of users that have been adopting the Cosmos SDC. I think it's also like go, the language has like become this. I might get some ridicule for it, but it's kind of like Java-esque in the enterprise world. world that people are willing to adopt Go in nowadays in the larger enterprise world. And so since we're written in Go and it's not like too complicated to write then, and it's fairly easy to understand because it is somewhat opinionated right now, then people are like, okay, I can come

and do this and I know it works. But I mean, I have also, so like in the past when I was in meeting SDK. I spent more time playing around with different frameworks. So I have built a few things with substrate, um, participated in a lot of Salonan and near hackathons. And I'm been keeping up with OP stack and arbitram and recently been, um, reading up on the hyper SDK and avalanche world. So it is, um, for me, it's like I'm not like a Cosmos maxi. Um, according to Sunny, everyone in Cosmos is like a Bitcoin maxi at heart. Um, so it's like we're just lovers of tech and we'd just like to see what other people are doing and like how they're doing it, but also learn from each other. I think in this space and open source entirely,

like, it's an amazing place to like learn from others and be able to grow and really reshape what you're thinking about. And so been keeping up with all those things and seeing the directions they are going and how that can influence the SDK. And then also with some of the teams, we also do talk on a regular basis. And so we throw ideas at each other. And so we're, we throw ideas at each other to try and challenge what we can do with our frameworks. Yeah, I think one of the core, like I guess always like selling points of cosmos in general, right, is IBC and sort of the promise to be able to bridge like without having to have some like sort of multi-sig bridge and just doing it like natively sort of more or less in inside the between the protocols. And I guess that's

also where I at least see like some of these other frameworks that don't have IBC sort of maybe struggling or like trying to some different approaches. Is that like correct in your sense? Or can you explain a little bit how IBC fits in the Cosmos SDK space and maybe like how even other frameworks or how are they approaching interoperability? And if that's, if that is like one of the unique things in Cosmos or if other frameworks can also adopt IBC and kind of the current state in your opinion. Yeah, definitely. I think IBC has a lot more potential than only Cosmos. And I think the Cosmos SDC is enticing for a lot of users because it's just like, hey, I can launch a chain and immediately get access to other chains. They don't have to launch a module

or smart contract on my chain. I don't have to do these partnerships. It just becomes trustless. And I can just launch it day one. And like the ecosystem in Cosmos to relayer ecosystems are very willing to just run relays right now. There is there is like fees being worked out in protocol fees for them, but the growth of IBC has really helped shape Cosmos and the users of Cosmos. Definitely other frameworks, it's interesting to see. So at the core, IBC is more, it's a library as well. And it's like you can really compose different clients. And so when we look at IBC today, everyone's like, oh, this is like Cosmosis thing. But at the end of the day, the implementation within IBC Go is a tendermint like client, um, very

get verifier. And so if you were to, but this is only a single client, you can have different clients for Bade, Grandpa, Hot Shot, all these different consensus protocols. And also that once you get out of consensus protocols, you can have different, like you can have fraud-proof clients, you can have validity-proof clients that like IBC now can work within these different ecosystems. And this has been like a thing that's gaining adoption within the IBC teams. And so they are working on expanding it. And I only see it benefiting the Cosmos SETK even more because all of a sudden, like, if you can communicate trustlessly and establish connections between rollups a lot easier than, hey, we need to go get a bridging protocol to come in and deploy on us. We have to go do BD.

We have to go do partnership. We have to do all this stuff to, oh, like, I can connect to base day one. and not have to worry about anything I can do like interchain accounts with base. I can do inner chain accounts with the optimism, I roll up or with Zora or with all these other things. Then it's all of a sudden a huge game changer where people were like, okay, in order for me to find product market fit, I need to build something that also uses all these other protocols. And up until now it's been pretty siloed in like how to get that adoption. So, yeah, let's see how kind of like Cosmos SDK compares to these other frameworks that you've experimented with so that they do like substrate.

Maybe we can start with substrate. Yeah. What are the big differences between Cosmos SDK and substrict? Well, first of all, it's within Rust or SCO. And I love to say that like blockchain people just love Rust over anything. And so, but substrate is like the, I'd say it's very abstracted and the API surface is very large. It's an amazing product. And like, as we've seen, like, Avail is written using substrate.

They were able to really accelerate their development cycle. And then we have the StarCad Sequencer, Madera, from the Lambda class people. And they're using substrate as well. And so it's very useful in what you can do. do. I think it's like as you go down the stack, it becomes more and more complicated on how to swap out certain functionality. And then also substrate now has this direction that they're kind of going in a more direction of Wazim instead of native. And I think like the, that is like a really good direction because you can have like more swamable things on the fly. But the downside is

the user base kind of becomes limited because now the user base has to do everything within the wasm vm instead of doing it within native rust code. The writing and how you write a substrate, they call it a palette or a frame, I believe, has progressed a lot over the years. And for me, many times, it's like if you're writing a new Rust SDK for rollups or chains, it's very hard to compete with substrate just because it has so much functionality already there that like if you were to try it, then you're always going to be at least a year behind substrate. So substrate's been really good. Slawn and NIR are like there I was playing around

with salon in the early days. It was a bit of a struggle to write contracts in the early days. Now it's become a lot better. But at the same time, it's like you're developing a smart contract over a or an application specific chain or a roll-up. So it is a different world. Same thing with near. Nears U.S. U. They did a lot of focus on it. So it has been only getting better. quite simple to understand. But now it's like, now when we dive into like what's going on in the roll-up space, it's all solidity. So like there isn't really a comparison.

It's just like everyone just uses solidity. So it's like if you write a solidity contract in one place, you can kind of carry it over to 10, 15 different other places just because it's all the same thing. Right. So even these frameworks like for OP stack or something, they are written in solidity. Like OP stack is like written in go. And I think Arbitrum's stuff is written in Rust,

but they have like a, they call them Wavum. But it's like you end up deploying your code as a smart contract. Now you can do pre-compiles with OPSEC. I believe you can write them in different languages. So here it's like you're using Go versus Rust again, but you're using a lot less of that code of that language. You're kind of like defaulting always to Rust because it's you launch the OPE, you launch the roll-up,

and it may be you or someone else running the roll-up, and it's usually a centralized sequencer, and then posting data, but you don't have to worry about any of that core low-level stuff. It's all you really care about this solidity. I guess actually something that I wanted to ask is also around, like, you know, I guess a lot of the people are now building Infragan

we're in the bare market. There's not that many applications there is. Liquidity on Ethereum, which probably explains also why a lot of things are focused around Ethereum in general. Now, I guess all these SDKs sort of also don't have really like a business model, right? Now,

I guess there has been this struggle in Cosmos for the longest time since it was designed very, in this modular way where essentially like, Adam, some people were even questioning what's the value accrual for Adam if there's like not the applications there, right? And then sort of ICS came along to kind of solve it a bit to basically go back to more this model where like the core chain like lands the security and can through that generate value for the core the token. Now, you know, how does that interact with SDK and what's like sort of your view of how this future plays out, like, what's the role of the SDK in these, like, sort of token world and then value accrual? So it's like you definitely bring up a good point where the cycle of like value accrual in that question is coming a lot faster in these other ecosystems. And it's like, okay, now like everyone's launching a roll up with these different stacks. and maybe one of this,

maybe these stacks kind of like optimism and arbitram have their own like roll up or chain. Now how does the value of cruel come back to their token? Ethereum is a bit like pushing that like, oh, a roll up is technically a definition of a rollup is something that burns ETH. And so in that world, it's like how if you shift away from like burning ETH

and all of a sudden like what is the value of cruel, then how do you like stay aligned with Ethereum? in Cosmos, yeah, it's definitely been a hard and it's definitely hard being at the core layer just because you kind of have to always ask this question and working closely with the ICF. They're also asking this question and like informal us, IBC team and many other teams are always kind of like thinking like how can we get funding from other teams as well because like the ICF funding won't last forever. And so it is a hard question, and I don't think we have a clear answer right now other than like, oh, let's go to community pools and like seek funding there. But I don't think that's like an end-all be-all solution. It's definitely like we can't change the licensing.

The interesting thing about Cosmos is if you contribute to many other ecosystems, as a contributor, you have to like sign a CLA, like sign your contribution over to the company operating or facilitating. the maintenance of the project. In Cosmos, it's actually all developers own their own contributions. And so we can't necessarily change the license of code because we don't own all the code. Or like, us the maintenance team and so on don't own all the code. It's the code owned by the ecosystem, by the contributors.

So that makes it even a bit harder because it's like if you want to shift the license, then all of a sudden you need to seek approval from everyone who contributed over the years and becomes like a larger issue. With the roll-up space, it is interesting seeing in like in Paris at ECC, people are already talking about like the fragmentation problem that's that they may have seen cosmos and other ecosystems run into that, okay, now you have all these chains interconnected, but now you have USC issued on all these different chains and now how do you like interact and you get this

fragmentation of liquidity, fragmentation of use? users, how do you bring that all together into like a single solid, like, let's say, front page for new users instead of having to go search across like 50 different front ends. And it's interesting to see that like that conversation is coming up earlier and it's going to be interesting to see what's come up. But at least in Cosmos right now, there is definitely a big push to try and align all these different apps, kind of create an app store. But I think And past that Past the App Store There's also a lot of things that are

Like IBC that users are trying to make seamless So like Skip is making it That you can unwind tokens with IBC You can swap tokens You don't have to have gas On this other chain that you want to do the swap Or something like that And that it just works out of the box

And these sort of UX wins Is what's going to be really beneficial To end users because now all of a sudden, when you go to a new chain, you have to have their gas token and they do it, in order to do that functionality. But now it's like, hey, I want to swap X for Y. I don't care what chain or what liquidity pool or what decks you go through. It just works.

And it's kind of going to be in that direction. So there's going to be a lot of these aggregators that start popping up in Cosmos. And I think in the wider blockchain ecosystem, Squid is also a good example that it's just like users interact with that. the end user doesn't know where the funds are really coming from. They display it, but probably the pro user cares, but the normal retail user most likely just doesn't care. They just want something to be received when they send something out.

Marco, it seems like Cosmos SDK is one of the most mature stacks to build an application-specific blockchain. and then you have all of these VMs also working on it, right? So the EVM specifically, but Cosmwasum, Avolic VM, all of them are working. Why is it that a project like optimism needed to build their own SDK or like blockchain development framework and why could they not borrow the Cosmos SDK itself for that purpose? is there something in the Ethereum ecosystem where compatibility with the designs of L2 bridges means that you need to develop something on their own or could actually like the Cosmos SDK stack

be used to build L2 in the Ethereum ecosystem? So I think like, I mean, there's multiple answers and there's definitely a lot of people everyone you talk to will give you a different answer. I do think that Cosmos SDK like in its current form or the form that it was when optimism decided to build out the OPE stack, what was maybe not fitting their use case. And maybe it was like too cumbersome to build with SDK. They needed to modify too much to the point where it was just like, okay, and just might as well build their own since it's kind of like that's what we would be doing anyways.

And secondly, I think like I believe the OPE stack started from like a fork of geth. And now with like the bedrock upgrade, now it's like their own thing. So they kind of like shifted from a fork of get to. now bedrock and became their own things. So it was a clearer path for them to do that. We hope in the future that like users, so right now

everyone's kind of like on the OP stack and it's kind of like the VC buzzword to like be building on the OP stack. And that's like a whole whole different conversation about like pitching yourself as a builder on a stack. But we hope that like in the future

with a lot of these refactors with partnering with teams like Bulletkit and dimension that when you go to build a roll-up, now all of a sudden it's not anymore like, oh, I want to, I'm going to build the OP stack because that's like what everyone else is doing. It's like, okay, now you really ask like, what functionality do I want and what functionality

do all these things offer? In that comparison, like to a certain level, there will be like the Cosmosis SDK. Like there are websites already popping up on these like RAS website that roll up as a service. That is like you can deploy a dimension rollup that uses the Cosmosis SDK on the website. hood. And this, this becomes harder and harder because it's, so like dimension and roll kit,

everyone's going to be like deploy a roll kit or like if you're using, if you want to use Polaris from Barrett chain, like the deploy a Polaris roll up. But on the back end, you're most likely using the Cosmos SDK. And so it's like we want the, so it's like the Cobbos test K's goal is somewhat to transcend cosmos that it's like, hey, like if you're using this framework or using this virtual machine, you don't necessarily know you're using the Cosmos SDK, and it's just kind of like there for you. We hope it goes in that direction, and we're really pushing to go in that direction. But I do think it was a good choice by optimism to develop their own stack because of how the SDK was back when they made the decision.

Yeah, the infrastructure, like everyone's kind of, it's very easy to raise money. And then in blockchain, I'm not. not like I don't mean to like call anyone out because it's like Cosmos is the same way and like everyone is the same way that we just love rebuilding uh rebuilding the wheel and so instead of like kind of like using something out there it's like oh like we can do it ourselves better and then it's like you'll lose a year developing it um and it's kind of like been the kind of drum that everyone kind of ends up in and then we have other users who are using Comet and when I talked to them about the Cosmosis SDCA they're like a year into building their state machine.

and they're like, yeah, we should have just used a cosmos SDK because it is very hard to build your own state machine. Right. I definitely think that is sort of the case. If you just look at the cycle and then how it plays out and how the new bus comes along right now, again, I think. But maybe, you know, out of all of this experimentation, right, I guess that's sort of the thing too that the best emerges, right? There's also like a competition and we, with a better infrastructure to actually build applications that users use when they come. So I guess that's the hope. I do think maybe because we also had the hyper SDK, Patrick on from Avalaps,

maybe you can, can you like explain? Because I think his, or I guess their approach is much, it's very like performance focus, right? It's kind of like he's building this thing to like really be super like performant versus and I guess maybe just your views of what they're building and how that maybe works in a like IBC Cosmos SDK world can they interoperate

somehow or how's your yeah I think I mean hyper SDK is like very cleanly written and like hats off to Patrick and that team it is very performant I do think it's like a definitely a different approach to users and I also think that their license

has like some weird like need to use need to build on Haba to be able to use it or something like that um I thought I read that a couple weeks ago. The SDK is like, so the early days of SDK was always like on liveliness and safety. And this has kind of been the cornerstone of like tendermint and now Comet and also

IPC. And so it's always been safety and likeness. And performance hasn't been the highest kind of like priority for the Cosmos SDC and the interchained stack as developers. Now this is all shifted. So it's like we do feel comfortable with the amount of safety and liveliness that we have achieved within all these different layers in the stack. And now it's like now we're rewriting or refactoring levels to become extremely performant. And so we are moving in that direction.

I do think that like there is a team that's like building on AVA and that's integrating IBC and kind of like the entry point into Avalanche. So there is like exciting stuff going on that like IBC is going beyond. but I do think within their world like they they would kind of need they would kind of need IBC to like go out of avalanche trustlessly without a multi-sig bridge but within like their subnets

there isn't really a need for IBC because they have their own communication protocol that fits their needs and so it's really IBC like we kind of in the early days it was oh like we have blockchains but now all these blockchains are silos we need a bridging protocol.

And then now we have multisig bridges between ecosystems, and then we have trustless bridging within ecosystems. And now the question is like, how do we get trustless bridging between ecosystems? Yeah, to me it does seem that, you know, because everyone else, it seems like from out, from some observations, I guess, that pushing more their stack and like trying to blend the token

and even these licenses, what you mentioned, Mark, where the Cosmos approach is the most friendly to like outside contributors and sort of adoption, but I guess there's still pressure from all these investors and from value accrual to maybe like not use that. So yeah, I do think maybe this is going to remain an issue for a long, long time. People in Cosmos and Pocod ecosystem like three years ago, like you could raise money saying you built on Pocod, right? Two years ago, you could say, you could raise money saying you're building off the cosmos, building in cosmos. Now you can raise money saying you're building off the OP stack or something.

Next year, it could be something else. And the year after that, it's something else. And the thing that always comes back to the team that's sold as we are building on X stack, now the BCs come back and say, hey, why are you still building on that stack? Why don't you go to this other stack? And it's just becoming more and more like, hey, like people, like a friend of mine and got asked the same question from a VC like, hey, why are you still on Pocodon? and it's just kind of like, the stack doesn't necessarily matter.

It's like asking like why is the backend written on Express instead of in Node.js instead of Rust. It's like it doesn't matter as long as there's a product that people are using on the front end. One of the big differences between the Ethereum ecosystem and the Cosmos ecosystem is, in the Ethereum ecosystem, like one can imagine like the roadmap of having all of these roll-ups or L2s as being focused on developing a new form of bridging technology, meaning that the idea is that if I am on Ethereum main net and if I bridge some tokens onto an L2 or a roll-up, if some misbehavior happens on the roll-up, I can go back to the Ethereum mainnet, presumably submit some kind of fraud proofs,

although that functionality is not live on many of the L2s today, but the ultimate vision is I should be able to present a fraud proof and get my ether or my ERC20 tokens back on the DCDM main net. And one can really imagine this as, okay, this is a form of bridging technology. It's a bridge with kind of like fraud proofs

on one side, but you could also imagine that same technology being like fraud proofs on other side, meaning if I my tokens originated on the roll-up, if I took them to Ethereum and then there was a big hack of the Ethereum network itself, then I should be able to go back to the roll-up and claim my assets back by submitting the fraud proofs, the proofs of the fraud on Ethereum back on the roll-up. So you can think of like really the centerpiece of Ethereum's ecosystem roadmap is bridges should be built in that particular way

and it is really opinionated on that being the correct way to build bridges. The Cosmos ecosystem, well, bridges are kind of like built differently where it's actually pretty much the same functionality except that the focus is not there on fraud proofs and being able to reclaim your assets if there's visiting behavior on the other side.

So meaning if there's two chains A and B, if I take my assets from A to B in the cosmos ecosystem and there's a major attack on chain B, then I necessarily don't have out-of-the-box technology to go back to chain A, present some kind of fraud-proof and get my assets back. It is assumed that if that case happens, well, the community

will figure it out. The software developers will figure it out and get the assets back and in the right hands. Like, why do you think this difference exists and why doesn't the cosmos ecosystem also invest in like fraud-proof technology? You could say that social consensus is more the Ethereum way than automating it.

But no, I do think so. the Slesia team worked very hard to get fraud proofs working within the SDK, like a single round fraud proofs. And we are working on like upstreaming it and like working and allowing teams to use it. And so there will be like better functionality out there to use fraud proofs. We are experimenting with different like commitment structures to do different things to make it more efficient. And or we're going to start researching in the fall and leading into the next year. around validity proofs and how we can really play around with

validity proofs and also like ZK technology within the Cosmos S-K just because the Cosmos ecosystem has somewhat been lacking in that space. I'd say it's just an area that hasn't been

quite explored that drastically yet, but there's becoming, there's more and more discussions coming up and so the Cosmos HUB is talking about doing like more of a social consensus fraud proof until fraud proofs are like kind of proven to work in the SDK and the cosmos SDC. And then there is osmosis recently announced that they will be working with Celestia and using fraud proofs for mesh security related things. And so there is

an adoption of fraud proofs and different types of proofs being adopted in the Cosmos ecosystem. But I will say that we are lagging a bit compared to, I mean, not necessarily. because like you said, there are some roll-ups that don't have fraud proofs yet. I mean, they're still working on it. And so there is a world that there is a, you could say that like we all are exploring it the same way other teams are exploring it as well. Yeah, I guess it might just not be as central to the narrative and like, I guess for Celestia maybe more so than other causal chains. But I guess in Ethereum, you have to like highlight that you're doing this to keep the Ethereum community like on your side. way. Yeah, to make people happy. And so it's been talked about here and there in Cosmos, but yeah,

it's kind of like, oh, like someone talks about it, brings it up. We talk to teams about it, Dimension, Osmosis announced, Celestia and so on, and different ways to like design with roll kits in mind and with, I think it's Diamond from Dimension in mind, like how to do with fraud proofs. And so there was that discussion going on. It's just not front and center. Right. Cool. Yeah. I think we're hitting the hour marks as a very good discussion.

I really hope people learned a lot about like, I know, blockchain specific frameworks from the OG himself and like probably one of the most knowledgeable people across the ecosystem. So really exciting to hear from you and being able to hear like the lessons you've learned over the years. I think maybe, To wrap it up, we can talk a little bit about, you know, what, where can people get involved with the Cosmos SDK?

How do you get in touch with Team? How do you build on the Cosmos SDK? Yeah. So, I mean, there's multiple ways. And if you're a new project and not only need technical help, there is the Interchain Builders program. And it's not limited to blockchains. Like if you're doing a roll-up using any part of the Interchain Sack, like you could only be using IBC. you could be using Comet, Rollkit, the Cosmosis, SCA, Cosmosin, the list really goes on. If you need help with anything outside of the tech, you can definitely go to the Energy and Builders program. And then for Tech-wise, really our Discord and our GitHub discussion board,

so if you go to the Cosmos GitHub organization, there's a community discussion board where we're constantly answering questions, about the Cosmosis S Ska, how to build with it. And there's tutorials. They're being updated for the upcoming release. The ecosystem's really excited about that. There's a lot of fixes, a lot of deletion of code for writing modules and interacting with VMs.

And so the UX is only getting better. Awesome, Markler. Thanks so much for coming on to Epicenter. And yeah, have a great week. Mike Rice, thanks for having we. Thank you for joining me. us on this week's episode. We release new episodes every week. You can find and subscribe to the show on iTunes, Spotify, YouTube, SoundCloud, or wherever you listen to podcasts. And if you have a Google Home or Alexa device,

you can tell it to listen to the latest episode of the Epicenter podcast. Go to epicenter.tv slash subscribe for a full list of places where you can watch and listen. And while you're there, be sure to sign up for the newsletter, so you get new episodes in your inbox as they're released. If you want to interact with us, guest or other podcast listeners, you can follow us on Twitter. And please leave us a review on iTunes. It helps people find the show, and we're always happy to read them. So thanks so much, and we look forward to being back next week.