Understanding CosmWasm SDK with Larry Engineer

Transcript

we are live I'm sub 3.0 and today I'm speaking with Larry engineer which a lot of people know in this space as uh the developer of Delphi Delphi Labs sorry I have a little issue here and today we're going to be speaking about Cosmos Cosmos SDK and why he's building Cosmos from SDK it's an interesting project because it aims to be like an alternative to the typical sort of like go SDK we'll be talking about some of the technical complexities of building this thing the architecture and also I'm willing to find I'm dying to find out why Larry thinks app chains don't need to be

decentralized uh before we get started please make sure to subscribe hit the notification Bell and like button to get notified when we do new live streams every week my guest Larry engineer is coming up next right here on the interrupt thank you hey Larry hey is that thanks for joining me um yeah so thanks for doing this and

before we get started uh yeah maybe uh tell me a little bit about yourself and because I know you you've been working in the cosmos race for a while and like you were previously building uh in the Terry ecosystem so you know for those who don't know you um what have you been up to these last couple years and how did you come to become a developer at uh at Delphi yeah so my day job is a developer at Delphi Delphi Labs so we have a couple different arms we have a VC arm we have a research arm and the labs arm I'm in uh we build protocols right so it's my day job and I contribute to a lending protocol called Mars so Mars was initially launched on terra terra classic

specifically back in Spring this year and it kind of it worked well uh for a couple months until they died together with Terror classic and so now we we are re restarting this project and hopefully launching soon on many Cosmos chains so um yeah I mean today like I'd love to spend a lot of time talking about uh Mars we're going to do another episode probably in a couple weeks with one of your colleagues uh diving deeper into Mars but just kind of a high level like what is the Mars protocol and what's the long-term Vision here for this project right so Mars is a lending protocol meaning

you can deposit assets into it and people can borrow them against their collaterals so if you have been using rvm compound it should be pretty familiar experience but on top of that we also have a new primitive called credit account which basically means uh you know deposit assets into the learning protocol you retain control over them you can borrow some other assets against your deposit collateral but you can still use all those borrowed assets and deposit collaterals in productive uses such as put them in yield Farms Etc um I believe this gives a lot of more flexibility to users and

pretty bullish on this idea yeah it's really cool like if you can use your collateral to do other things I've also seen um some lending protocols that are like kind of starting to to think about um building and that leverage staked assets uh for collateral is that something you guys would possibly also consider doing yeah yeah there's definitely something that our credit comp can can enable cool so basically you started building this on on Terra before the Terra collapse um what was it like building in that ecosystem like I I you know I like I wasn't super plugged into like all the stuff that was going on there but I know that like there was a lot of activity

um what was it like building there and how did it feel to like have to transition into the cosmos ecosystem was that pretty seamless for you or uh yeah how'd that feel yeah it's very seamless because we uh because these different Cosmos change they all use the same uh smart contract framework called causing mozam because we are going to talk a lot about in this episode so so it's the same framework it's a pretty smooth transition uh the only difference I would say is that Terra and synchron network are the two earliest adopters of custom model and by the time we were working on terad the customizing virtual machine is pretty

different from what it is now and yeah so so that's why you see some some protocols who started on her a bit later are going to restart much faster than than we are able to do because they we built our protocol um a quite old code base and they they entered later so they built their things um earlier a miracle basis so they can transfer faster that that doesn't phenomenal we see quite often in crypto it's kind of interesting that late camera usually have have an advantage in a very fast moving kind of uh kind of feel yeah so you guys were

building on an older code base and so therefore there's a lot more like refactoring and catching up to do in order to be like compatible with yeah the basis of Cosmos yeah adapting so newer framework is one thing another thing is by the time when we were building Mars the whole thing was still new uh nobody knew how to really properly write contracts meaning nobody knew what's the best practices uh and those things all had to be figured out during the time hello yeah yeah the cause of Muslim um space has been like really interesting to watch like I think you know like a year ago there were very few people talking about

cosmosum I think like very few cosmosm developers at least in the in the cosmos ecosystem um but since um since the Inception of Juno and you know cosmosum uh being implemented on Cosmos chains it feels like now it is becoming such a massive part of the cosmos narrative and more and more developers are turning to cosmoasm and yeah Cosmos Academy why do you think cosmosum is so attractive as a platform for uh for Builders yeah so I can talk about this on two sides for uh one in comparison to ethereum whose

primary language is solidity cosmolism the primary language for causal model is rust which is a modern language compared to saluhi which feels just pretty Asians and rust is probably one of the best modern languages uh so when when using cause and models we can leverage all the all the benefits from rust including its package management uh it's excellent compiler all the ecosystem tools so in my opinion it's just a better better experience and a good story we would like to tell is that um

so wasn't contract is actually pretty big so if you write a contract in solidity you actually have a hard cap of 24 kilobytes so your contract cannot be too big but for for waslam it's pretty usual for your contracts to be you know a few hundred kilobytes so it was pretty big and that was kind of a little worry but that at one point there was a rust released a new release of the last language and that that come packaged with a an optimization that reduced all our contract size approximately by half so like we as smart contract developers we

did nothing we just upgrade our rust language and our contracts all reduce have insights so I would say it's it's a it's a benefit of working in this deck like we get to enjoy all the Upstream benefits from from rust from all the other people programming in grasp for all other purposes we get to enjoy all those benefits um so that that's in comparison with ethereum oh I forgot to tell about all these security uh all this all the security design considerations put into Cosmos and a lot of the very common hacks vulnerabilities in solidity contracts simply don't exist in cosmosis like you might know there is a

vulnerability called re-entrancy that that is what caused the the dial hack back in the days that vulnerability simply doesn't exist in causal Muslim like you you can't even code every entrancy vulnerability even if you want to it just the virtual machine doesn't allow that fundamentally um and this is just one example a cosmoplasm it's much fun to write um it's much more secure it's just a major pleasure to work with so that's the comparison with ethereum I was about to say the comparison of this Cosmos SDK but yeah please go ahead yeah oh okay yeah so

so the thing with Cosmos SDK is that it offers you very low level control of your application which can be good in some cases but in my opinion bad in in Market in more situations uh what do I mean by low level control so you have to to implement in various simple functionality you have to write a lot of code so let's say you just want to store a number on the blockchain what do you have to do I'll have to Define a transaction type for updating or storing that number you have to define a query tab for for querying that the value of that number you have to define a command line

interface command for manipulating that number you have to define a grpc endpoint you have to Define rest endpoint uh and you have to hook up this thing with all the other modules in your blockchain so it's just a lot of work for for implementing a very simple task so I actually counted this so storing a number in a contract is literally one liner in solidity uh it's maybe five six hundred lines in in the go SDK and and let's say you want to that's not the worst the worst thing is if you want to upgrade your application you need to

change a few things every time you change it's a little bit here just change it one night right but in go SDK we got probably like 10 20 different places you have to change in those five six hundred lines so that's that's a very painful thing to do and that means iterating new designs uh implementing new features in go SDK is significantly uh slower than if you are using other stack text yeah I'd like to come back maybe just I mean I do want to address the complexity of you know building the go modules and kind of the trade-offs of using cosmoplasm versus uh go modules but coming back to what you were saying

about you know rust and and um and wasm as a as a as a sort of development environment you know like early on in the days of ethereum there was some talk of uh ethereum implementing uh cosmoasm uh sorry uh wasm based contracts um in replacement for solidity uh of course like the polka dot team I think substrate uses uh wasm why do you think that wasm um this web assembly um Paradigm is so interesting for blockchains generally like even though ethereum hasn't implemented you know there was some interest there like other

blockchains are using was and why do you think that is well it wasn't is probably the single most optimized virtual machine out there so virtual machines meaning like you have let's say you have your physical CPU and that CPU has an instruction set so when you write a language it compiles to Binary instructions for that instruction set a virtual machine is a container that runs on top of that that is it that has its own instruction set and when you when you write your program it compiles to Binary instructions for that instruction set and will run in that container it needs to be translated to your CPU instruction set and run there so that usually is overhead because you have to like

have a translation step so VM usually comes with overhead that's the thing cosmoplasm is no I mean Watson wasm is probably the most optimized VM out there it it has near native performance meaning you run a program in the Watson container it's almost as fast as running it directly on on your physical CPU but so maybe just to explain here for for those who are less technical so when when you write a program let's say like it's C plus plus or you write a programming like some some language that has a compiler uh on on your environment you compile that language it runs

directly on uh on the CPU like through the through the um uh the the operating system but there's less layers of abstraction between you know your program that you're running and the underlying CPU that's processing uh that's that's basically executing State changes um with with a virtual machine whereas where you're running a virtual machine on a blockchain there is some layers of abstraction there that exist between the application and um and the the underlying data structure that is uh that is being updated all the time and because wasm is so optimized the performance of wasm uh will be higher than say like an evm because the

the virtual machine has nearly the same performance as whatever underlying infrastructure is there so there's like a lot less compute overhead for that virtual machine to run its programs than something that would be less optimized is that a good a good yeah someone actually told me uh cozum waslam is more performant in the evm I forgot who that was but that was a surprising result to me because evm has much smaller instruction set usually it's a simpler a VM is that the easier it is to optimize it so I I always assume evm is the most performance VM out there but then people told me wasn't was more performant so that that was a pleasant surprise yeah

we also have to consider yeah of course the instruction set right so like um in in solidity we have like a limited instruction set in terms of the language and what it is possible to write with that language and then with with cosmosm we're actually had like the full instruction set of rust is it the full instruction set or is it just a simple instruction side of the of water of wasm right okay almost almost everything in Rust except for a few things such as uh such as floating points or randomness can can be compiled into Watson instructions okay okay cool yeah I think that that sort of paints a picture of like what cosmosome is and like how how it interacts with uh

with with rust um so you've been talking about this CW SDK for some time like Sunny told me that I should talk to you about this and I started looking into it and I was like okay this is kind of interesting and like why is he doing this and so yeah what prompted you to build a start building uh because this is still in development and it's like it's not not production ready or anything like that but what prompted you to start building a uh sort of competing SDK or a complimentary SDK to the cosmos SDK in cosmosum yeah so for for a bit of context I just came up with the idea during Cosmos the conference um

and I I just started working on it back when I got back home which is early in October about a month ago and I I had a I had a small group of people who had the same passion so we have a little group uh working on this thing so it's not just me uh yeah so so back to your question like firstly we want to uh compared to compare it with the gold SDK writing your protocol in wasn't much easier much faster and you can iterate make make new things make new upgrades tremendously easier but I I would say what prompted me to work on this is when I look at our

ecosystem there are quite quite a few chains that doesn't really touch the go SDK they they Implement their entire protocol in wasn't and just deploy a very generic SDK chain with a lot of module and their entire thing is inside that wasn't container so an example would be kojira and Stargate so their Protocols are entirely invasive so um knowing that then I look at the technical stack of the go SDK it is tremendously complex quite complex so if you can uh let me show my screen or

is that possible or not I think you're you're immunity I think I know I can share the screen uh yeah that picture I think I think I seem to have it um I must tweeted that picture so Jacob from notion or tweeted a similar picture but the idea is it's the same so so you see are you talking about are you talking about this thing yes so this is the this is a structured diagram for the go SDK which it was a module so the the brownish color here is the rust language and the blue color is

the go language so what happens is in a very very inner layer that there's thing called wasmer that is it wasn't runtime so that is the program that reads the binary instructions from the from the Watson contract and execute them that that is in Rust right and and outside that layer you have column one and VM so that that is the core most most important part of the whole thing so this this one defines the standard input output and uh database access for for contracts so this is the actual thing where we run contracts and now the problem comes because you cannot directly embed a rust program

inside a gold program so you have to do a bit of hacking and the the way they they did that is they they write a thing called lid because it wasn't VM so that is the rest but that gets compiled to a system file that gets deposited in one of your system folders and the on top of that they have a goal program called wasn't VM which is like an interface layer for interacting with that system file and uh out of that finally we have the go module which is called wasn't um here I call it wasn't D because the

the GitHub repository is called wasn't D but the module is called wasn't just wasn't so that is the cosmos SDK module that wraps around what's in the end that implements the standard interface required by go modules how many of these layers are actually virtual machines is it is just one virtual machine or is this wasn't VM also like a go virtual machine that runs Cosmos virtual machine so there there are just layers of adapters and interfaces okay the real the real virtual machine are the most inner two layers okay yeah so so the point here is this tag is tremendously complicated um

and for so well this is kind of debated I don't think anybody has done very comprehensive benchmarking but according to Jacob from notional uh that that interface between between lib was and VM and wasn't VM is actually a pretty big performance bottleneck according to him right people don't some people don't agree but at least we know there are some people saying uh arguing that this this whole stack might be a performance bottleneck yeah so so just just to kind of recap here so so basically everything here in wasm D is

uh a cosmos SDK module uh that runs Cosmos I mean maybe just taking a step back um to maybe explain the outer layers of this as well so in any Cosmos blockchain we of course have like tendermint running which is the consensus module it interacts with the cosmos SDK through this application uh adci application Block Chain interface which is what talks to the cosmos SDK or any other application you wanted to build on this like my previous company we were building on tenement before there was a cosmos SDK and we were leveraging ABCI to do that and we had our own like Go app sitting on top of that so the cosmos SDK is just an app that sort of sits on top of tenement that interacts with

tenement 380 BCI and then that go app has all of these modules that have been developed like the auth module the the bank module that allows you to distribute tokens the the governance module the staking module the slashing module and there's a ton of other modules and these are sort of like pre-built blocks that allow one to build an application you know these are blocks that do things that a lot of people want to do without with blockchains right like like staking or doing governance or Distributing tokens or allowing accounts to uh to manage other accounts like the authority module and and this wasn't d uh block is a module in itself that allows an application to run cosm waza

right right okay um so this this whole stack here like one of the things you were mentioning earlier which which I thought was interesting is that whenever you whenever a user executes a transaction and wants to interact with a module like let's say they want to uh delegate tokens well there's a module uh that they would interact with so in their transaction like you said there would be a header that uh would call that specific module um and then that transaction makes its way through uh through tenderness can you can you just like describe the transaction flow like let's say I want to do something simple

like delegate tokens right so from the user onto the module how does that work so the user will compose a transaction um so that the transaction view contain a header so the the actual terminology is it's a type URL but that's it it's just a title of the transaction and the title will say this is a delegate tokens transaction the user is going to broadcast that transaction to Tender mint so that RPC endpoint which you can see at the very bottom of the bottom bottom left of the diagram yep um so tender men are going to maintain that transaction and many other transactions in its main pool right so

so let's say this this tenderness node is the proposal of the next block it grabs a few transactions from the mempool and say hey this is the new block and what it does now is it uses a method of the ABCI called deliver transaction to deliver that these transactions one by one to the application layer which is the that big box on top of ABCI and that all together we call them like we call it the application layer so the application layer receives the transaction via the delivery transaction method it is going to see hey this one has a header of delegate tokens that belongs to the staking module so

it's going to grab the data of that transaction give that to the stating module we will executed right um and provides a response to to tenderness via ABCI Ally that's that's super clear um yeah and one thing I I didn't uh one thing I'm not familiar with is the grpc stuff like what's this other stuff where the user can interact directly with the cosmos SDK I didn't as possible so so those are optional those are optional um so they are mostly for queries because uh so we just talked about how transaction

works but let's let's also talk a bit about about how queries works so query is kind of similar it also has a header it has a body so the user also broadcasts the query to the to tenement via RPC uh commitment are going to have used use another ABCI method called query to forward that query to to the application layer the application there will look at the header and forward the body to the appropriate module and return the response to condiment for your ABCI and kind of means it returns that to the user via RPC so so this grpc rest stuff they're kind of optional because you can you can

technically do everything via our PC alone you don't really need any of those but but those are probably more performant or familiar to developers like rest is very easy easy to use API much easier than RPC for for multi-developers so it just provide another option okay interesting all right so let's look at the other uh the other diagram which is this one um a lot simpler seems yeah at first glance it looks it looks Much More Much More simple yeah so what's happening here yeah yeah so if you if you just switch back to the previous picture real quick it just you can see the second picture is just wraps out the

uh if that work it just takes out all the brown Parts yeah other parts uh and put that directly on top of temperament right uh so basically all of these so there's like one two three these three layers here that wrap around the cosmom VM uh are now gone and we have just this SDK uh uh wrapper uh that interacts directly with sentiment right and here we have a very very thin very minimalist layer of software called CW SDK that needs to implement a few things uh among these it includes the database access so the application needs to write data to to a to a persistent

database uh that needs to be implemented in the cosmos SDK it is implemented in the Cosmos SDK big big box so we have to do include that here it has to right so uh in here the database access is in a big Cosmos SDK box right so we have to implement that we have to implement the ABCI so that our housing laws of VM can talk with tenements we have to implement Logics related to to gas to transaction fees to transaction authorization right so we're being broadcast a transaction you need to sign it we need the mechanism to verify those signatures

um and a few other Logics but okay yeah so the idea is it is very simple uh the the CW SDK is intentionally minimalist okay so I I guess it's it's kind of plain to see the the minimalism of of this of this architecture and but I guess I'm I'm curious like why though you know so so what what what kind of blockchain would want to implement uh uh cosmet wasm SDK and not have a governance module and not have a

staking module and not have all these other modules so it's like you know in practical sense where would those functionalities come from would we be able to also use Cosmos or sorry uh the cosmos SDK on the side here uh maybe like kind of over here we've got the cosmos SDK that runs those modules or would they be implemented in cosmosum what's the idea uh there are many reasons uh firstly it's minimalism itself is a good reason you have a if you have a very complex very bloated piece of software it usually means it's harder to audit there may potentially be more security vulnerabilities uh and it's probably less performance

so that so pin minimal is p simplistic it's in itself an advantage right and the second thing we do have these modules we do have gov we do have governance we do have staking but they are going to all be contracts running inside that Quantum container uh and the thing is because there are contracts they're super easy to customize so any protocol who wants to have their customized governance they don't like what we Implement by default they want to change super easy you just implement their stuff and swap out hours right um but isn't isn't the whole value

proposition of the cosmos SDK and Cosmos SDK modules that these things have been like vetted and tried and tested and audited and like there's just a ton of eyes on this thing so that you you if you're using the staking module are you using any of the modules in the cosmos SDK you have a high level of certainty that um that there will be no vulnerabilities or bugs or like whenever things are found like the entire ecosystem jumps on it and and updates wouldn't we lose some of those benefits by implementing everything as like all these kind of reusable pieces as cosm wasm contracts

um that can be one argument but I can I can show you something right now so [Applause] I'm just using a cool account the line of code in in Cosmos SDK so in the latest version of Cosmos 7K that's to say the bank module um the vent module has 19 242 lines of gold code okay so how many lines do I have in my bank contract uh let's see less than a thousand right Bang

anybody want to make bets I have 1824 lines so okay last less than 10 percent of what the goal code has uh so you might say that twenty thousand line that go SDK had has been audited for many years but we only have one tenth of the code in my opinion it's easier to audit so okay no I mean it it's like yeah having having less code of course like makes it easier to audit makes it easier also to make like changes and things like that but um

yeah I guess I guess it would be desirable if uh there were kind of canonical modules and I I suppose this is probably the idea is that like there's a canonical Bank module there's a canonical governance module there's a canonical like all these different modules uh people looking at the source code will be able to see that you know a chain is using you know the the contract that has been like tested embedded by the community for many years and if you're like using a different contract then you probably have other assumptions about like how that contract should be audited or or like uh you know some additional security measures uh needed to uh make sure that like this contract is secure is that kind of like the idea

yeah so another Point another complaint I have with the goal modules is that they're all kind of based on like 2017 2018 designs and after all these years of development in in you know in our ecosystem we have a lot of new needs but we cannot very quickly Implement changes to the cosmos SDK because if you Implement those changes you break all the existing chains and actually I think that that kind of contradict contradicts with the app chain thesis a big reason without the app chain thesis is that each chain can independently

upgrade regardless of what other protocols do so on ethereum we cannot do this because if you if you change and change an instruction in the evm it potentially breaks all the existing contracts out there so even if I need a specific feature of the evm I cannot have it because that breaks everybody else but this app chain I have full control of my execution environment I can customize it however I want regardless of what other apps do that's the benefit of of use of app chains but we have these very pretty pretty old pretty bloated go SDK code base it kind of kind of have the same problem with

ethereum right it just cannot iterate very quickly and just let's say I want to Fork the cosmos SDK with some protocols like osmosis already do um as I mentioned you make one small changes you need to change in 100 other places because of that's just how the code works it's just very painful and when you change all those 100 other places you might introduce a bug and it's it's really hard to figure out because you have 20 000 lines of code in just one module yeah yeah do you think that there's like some Middle Ground where you know the the main modules that most people would use

like things like staking like Bank um would be would continue to Leverage The Cosmos sdks modules um but new functionalities and this is something Sunny has been talking about like he's talked about it here before on the podcast as well is having um you know some form of permission to cosmosm deployment on chains such that new functionalities can be built and that maybe the Innovation space uh uh it should should happen here instead of like creating a an entirely new stack um that competes with the cosmos SDK and all the kind of money and resources that are behind it I think competition is is good that's my

point um you see a short while back we have to do this operated called Dragon Berry because they're also vulnerability in in the ivl tree right um in my opinion it would be good if we have two competing stacks and if something breaks it doesn't affect everybody it only affects those using one specific stack right in that case we have diversification in terms of software Frameworks I think that's a good thing yeah no I tend to agree with you that like diversity in in the software stack is good

um yeah it seems like so so what's the like what is your goal here to to to duplicate many of the functionalities of the cosmos SDK um in uh in Rust and like what kind of resources do you hope to like I know that you've just started working on this but is this a project that you think can you know get public goods funding maybe even funding from I don't know like the ICF or or other funding bodies in the space like hire a team and really build this out as a competing uh SDK that that's a very good question because

uh what we're building is probably good it is open source software everybody can use for free um so this piece of software that by itself doesn't make any money so in my knowledge confield the company who created custom model they have been wanting to do this for a long time but they couldn't do it because they are a company they need cash flow they need to pay their their employees they just cannot do a project that brings no money right so it's impossible for them to work on this it's it's just by people like me who who I already have a a job right I have plenty of free time and passion it's

only people like me and and some of other my friends in the group can can get this down so so yeah that's all I think yeah but I mean like it you know like you you've got a full-time job and maybe even some of the other folks as well do but like if if cosm wasm SDK is to become a a stable and like serious competitor or not competitor but like alternative to the to the cosmos SDK to the to the go SDK do you think that at some point it will become necessary for it to um have like full-time maintainers uh

maybe different teams uh contributing to it like even coinfio um participating in some way like they it's it's a big undertaking it seems like I mean if you want to have like something that's feature sort of feature compatible that has the same security guarantees where um new projects can you know um really look at this as a Bible alternative that's secure that will maintain like upgradability over time Etc like you'll need more than just like you and a few of your friends right yeah well this is something I hadn't considered yet um but I know it's early but I'm just like thinking along term if it's yeah because

it's a cool project yeah like yeah we're not only competing with the cosmosis decade we're also competing with IBC goal so that's the goal implementation of IBC we're also going to have to have our cwibc like IBC modules implemented in contracts so you know so that's the SDK team and the goal at IBC team they're founded by interchange Foundation who has a lot of money we don't so I guess this is something we this is something we do have to consider at some point but I don't have a good answer at this point yeah so I wanted to ask you about IBC and

like IBC compatibility um what's the what's the amount of complexity of implementing IBC as a cosmosum or a set of cause of water contracts and um what are the maybe some of the other unique complexities of maybe some of the modules that uh make it difficult to implement as cosmos and if any yeah I think IBC would be the most challenging um and it is challenging because because of the underlying data structure we use is different from the cosmos SDK Cosmos SDK uses the so-called iavl3 so

we need a three data structure in order to to generate a root hash of the whole blockchain state so that nodes can reach consensus by comparing that good hash right um so so ivl in in the goal in the gold team's own word is an orphan project it is only used by by the cosmos SDK itself it's not used by any other blockchain they have been considering moving to uh smt or sparse Marco 3 for a long time but they couldn't because that breaks everything that breaks all the existing chains uh so we we are starting from scratch and we we are using

another data structure called Merc tree which is created by Dynamic team so so it is actually more performant than imvl um but back to the IBC the problem is each tree data structure comes with a different algorithm for for doing miracle proofs so maybe you when you do IBC transaction the recipient chain needs to need a proof that your transaction and your data was indeed included in the state of the source chain so that for that you need the Merkle root hash you need the trace data structure and you need a proof and that

proof is unique to the type of tree data structure you choose so if we are using iavl we can just use their proof but for not uh for for mercury our own tree data structure we have to come up with our own proof format uh so hopefully economic recreated the treated structure maybe they can come up with the IBC proof format but that is one challenge part so I I wasn't I wasn't aware that there were different types of Merkle trees like I guess maybe I kind of was but yeah what's the what's the difference between with these

like what what are the types I don't want to do to describe like the difference maybe between these different uh implementations but what are the kinds of things that are different or what are the different considerations that say like uh this Merc or this smt or is it just performance or is there something uh that's that maybe like unique to the types of data that are being processed so they are just uh different types of optimizations but but these optimizations are going all go pretty far in their own different directions and they kind of develop into completely different trees in the end okay and so this iavl tree because I'm like

looking at GitHub right now so this iavl tree is um this the tree structure that uh the cosmos SDK has been using since the beginning but it's something that was developed um by it's like it was developed by the cosmos SDK team uh uniquely for Cosmos or was it something that was used like prior in another in other projects so if you look up Wikipedia search AVL tree which is like the the design behind that it was developed in the 1970s it's the first ever self-balancing tree in in the in the history of computer science so it's not a new thing they added their own flavor which is what the eye part comes from

um actually 1960s so not a new technology um yeah 62 yeah yeah and as of as of now iavl is the only well Cosmos the only chain using iubl so it's uh no one else is maintaining it it's kind of like uh what in their words orphan project okay uh so I can link you to and this is where the dragonberry bug was because not a lot of people have been talking about like what happened yet I don't as far as I know there hasn't been a whole lot of like disclosures about what Dragon Berry was at least to the public but it wasn't this repository that there was an issue I'm not quite sure about dragonberry but

the finance hack is here okay got it interesting okay I'm gonna have to hold I'll have to like find someone to do a whole episode about just like Merkel tree structures then you've just opened up like a whole can of worms here um but yeah this is interesting this is the stuff I I I'm not super familiar yeah so in our group we also had a lot of debates on on what to use do we use Merc or do we Implement our own smt or do we use uh other versions of smt implementation like the number has one we consider using them but they have they lack some important features we need so we ended up deciding on Mark but it's

it it is a subjective change in the future okay so what what about like so so we're implementing IBC you'd also have to implement interesting accounts interesting sorry you also have to implement um um yeah intergen accounts uh yeah we need to implement uh Tony the fungible token transfer protocol obviously we we probably need interchange accounts I'm a bit uh I'm not it's not super high priority the industry accounts because for now not many Protocols are using it uh as far as

I know stride is the only one using it so yeah not super high demand uh I'm more interested in interchange query I had a very good idea on how to implement interchange query which I think is better than what Quicksilver has um why do you think it's better um so as far as I know I could be wrong I haven't been following it recently but I think quicksilver's implementation only allows the so-called raw query so it can only retrieve a certain value corresponding to a key in in the in the chains data in the change state but often what we need is we grab the the values we do some Computing on that

value and we return the computed result that is called a smart query as far as I know quick Server doesn't have Smart query so a good example of smart query is T WAP the t-wap Oracle so what team app does is it take the uh time average accumulated price of of now and it takes the accumulated price of a past time it takes a difference and divide by time and that is your average price over the period so you see you need two data points and you need to do a computation on that two data points and you return the computed result so so the idea is smart query is that this t-wap Computing logic is present in

the queried chain it is not present in a query or train chain so if you just give the query a train chain the the two raw values the query chain doesn't know how to do it it doesn't know how to do the computation to derive the average price only the query chain can do that but with uh my version of the interesting query we can have the Computing happen on this on the on the credit chain return the Computing result and generate a proof for that okay and actually I don't think my that approach is uniquely mine I think uh Quasar has implemented that as a goal module already but for

let's say diversity we have to do that as a contract so what are some of the Practical applications here and what chains do you think would um if any like existing Chains would benefit from leveraging the cosmosum SDK yeah so so among them obviously is are the so-called Watson chains which are chains that build their entire protocols in as contracts so fujira and uh stargaze R2 Juno I think is a good candidate and for Juno they have a unique uh unique reason

which is because they have Tao Dao if they migrate to cwsdk they can just have dialed out as their L1 governance yeah like currently on Juno you have started out but you also have the L1 governance module which are kills everything but but why because data is better why don't you just have dialed hours the album governance they can do that with city of SDK um so so let's just I'm thinking about Juno here so let's say let's say let's imagine Cosmos SDK you know like gets gets built out and it's like kind of feature complete and we can do staking and we can do governance and we could do all the things we can do with uh Cosmos with a go SDK

um then those modules sort of sit at the same level as all of the permissionless smart contract that people are developing so people can also develop other modules or other contracts that might be useful and and then you you kind of get the same composability benefits as you do with ethereum because contracts are able to call it the contracts they all kind of sit together on the same in the same name space uh and are able to call on each other it's very different I think from the um I think the architectural Paradigm that people think of when when they think

about Cosmos compared to ethereum and the composability that we have there within that ecosystem um yes composability it is another reason I I forgot to mention of uh why as we as cause and Muslim developers hate to work with SQL SDK that is for every new module you implement Indigo SDK you have to also program a thing called binding for in order for that module to compose with contracts um yeah so that's just extra work right but but if you use CW SDK everything is

natively contracts and natively comes with impossibility yeah yeah so a chain could uh build you know interesting uh modules that any everybody can leverage maybe even have um mechanisms for like treasury to pay fees on certain modules so like I'm thinking you know a chain could a chain could launch and and have uh a built-in decks for instance and like that decks could be um kind of subsidized by the change Treasury and like everybody could use it and it's sort of like a public good for everyone to use uh just like it could

have different modules that are core to a blockchains functioning like staking and governance and things like that but it just opens up the possibilities for what chains can offer in terms of differentiating factors between themselves yeah yeah certainly you can do that with the core SDK as well but it's just much easier to do to do that with uh with with the framework that is natively designed for yeah yeah and then what about the compatibility with existing tools and infrastructure so like the compatibility with say things like Min scan or even like Kepler wallet that Implement you know the the types of

transactions that uh are in the go SDK so they would all have to implement of course um the kind of native cosmoasm SDK uh calls as well right so we probably have to program a composability module just for that um because you're if you remember the the query and transaction has a particular format for the go SDK we mentioned it has a header I have a body right um so that that is the format that the core SDK uses it's called the protobuf protobuf is the software that uses for encoding for for causal model where Native contracts natively use a

different encoding format called Json yeah so for for CW SDK all the queries and transactions are in Json format so if you if you send them a protopath and hold it transaction or query it cannot decode it yeah so in order to support existing platforms like Kepler or minscan we will have to implement a computer compatibility module and essentially what it does is it receives a transaction it will first attempt to decode it using the Json format if if it decodes successfully all good you just do that

if it fails it will then attempt to decode it using the product format if that's successful it will translate that to into Json and handle it accordingly if it still fails well then that's an invalid transaction yeah so then you don't need to all of the wallets and other user-facing kind of applications they don't need to um to have native compatibility with the cosmos modules you just need to build um a module that translates say like a delegation call or a delegation transaction your the module receives that translates the protobuf

um into Json and then like passes it on to the contract yeah yeah well I mean ideally those apps are will Implement uh natively for for our stack yeah that's what I hope but it's backwards compatible but if they don't then we have this back backwards compatible thing okay very cool cool well before we I thought there's one other thing that I wanted to to talk about and like I've I've seen you Tweeting about this and I've uh also I think heard you talk about the necessity for like the cosmos SDK to be Rewritten in Rust um can you uh can you unpack this and you know yeah

yeah so um so a big difference developing coal and rust is that if you programming rust and the program compiles the compiler are happy with it then you are you have a very high degree of confidence that the program will work but if you write a programming goal it compiles the compiler is Happy there's still a very high probability that the program won't work because goal is not a very like let's say secure language like even if the compiler is Happy their mind still be be host in your application logic that lines let's say crash at some point but but in rest it almost never

happens uh and that that's actually one of the my favorite things about rust because it removed it moves a lot of the errors from runtime to compile time meaning if you have a problem if you can complain at compel time instead of it compiles just fine but you have to figure out why things crash during runtime so yeah I mean back to the question I guess my answer is that rest is just just a better language I I know there are a lot of Co enjoyers in the hospitals Community might not agree but in my opinion for us is a better language do you know if the ICF or informal is

because I think they're working on a rust implementation of IBC and tenement uh they they do have repositories called ibcrs or yeah all right but they're not full implementations they're just they're just a toolkit for people to build rust programs that interface with IBC or tindermint so they're not full implementations okay and do you know if there's any like what's the state of conversation around rewriting the cosmos SDK and Russ are you the only person talking about this so now make created their own application framework in Rust uh penumbra also I think uh yeah so they are already

existing rust-based Frameworks for building applications um but they are all like built specifically for their specific chains right so uh cwsk will be a generalized framework cool well um this has been really interesting I've I've learned a ton today um and so yeah I really I really like having these kind of deep technical discussions and getting to break things down and understanding all the moving parts and everything so thanks so much for uh for um yeah breaking down uh cwsck and like how it works and uh what your plans are for it like yeah what what are your

plans moving forward are you just gonna like keep working on it keep kind of building on it in your free time or do you do you have uh yeah so yeah I hope maybe by some point mid next year uh we will have a working product I mean working product meaning the SDK is working uh it can be audited it will be sent for all the teams right uh by mid next year and following that is actually the most difficult part because we we need to actually have a chain right uh yeah what would that change be will it be a general generalized smart contract chain yeah I don't think that would be a very good idea because we

already have like oversupply of generalized smart contract chains um right we have Juno Neutron archway right uh not to mention the evm ones yeah yeah we also let's just let's just say cousin wasm alone we have Picasso and landslide do you know those two names yeah uh Picasso is a polka dot pair of chain implements and IBC that's like it's an avalanche uh uh what's their word subnet with cosmosm and IBC so hey I didn't know that yeah so they're like really

exciting so like cousin wasn't it's actually bigger than Cosmos yeah it's it's a generalized smart contract framework for for many different um yeah so like generalized smart contract change and no goal so we need to build an app chain with the killer app to make it big but what would that app be I have some very early stage ideas not sure if they are good I think they're good but it might not be a more experienced eyes so we will discuss that in the coming months well we'll I'll certainly keep looking out for it

um and yeah maybe when when that comes out um we can come you can come back on here and tell us about the progress yeah so one final question uh who's one person you think I should have on this podcast um well so you already have Davide from Mars team Mark yeah he's coming on in a couple of weeks yeah yeah he's a big brain yeah talk to you about the topics here about the Mars credit account right yeah that has to be good um yeah sure about my controversial take

oh that's right we didn't talk about that okay so uh yeah yeah let's let's uh let's end on this yeah why do you think app chains don't need to be decentralized yeah so let's stop asking me what what is my controversial take like prior to we start streaming this and that that's what I that's what I like had in my brain at the time uh so my opinion is action don't necessarily need to be decentralized like have a very for example have a very decentralized token distribution that everybody have the same stake all validators have the same voting power I don't think that's the strict necessity it's a good half but it's not so and why is that so that let's think about why like we don't like

a very centralized political structure in a like a traditional uh let's say in Indonesian State we don't want the nation-state to have its power centralized in one person's hand um that actually leads to to very poor like degrees level of freedom for the people or level of uh uh quality of life right why is that because in traditional nation states people don't usually have a choice for for living like you cannot decide where you are born uh those authoritarian States usually Implement restrictions on travel to not enable you to leave uh and if you cannot

leave you you're stuck with their political economic structure you don't have a choice to opt out but that is not the case for blockchains right if you have a centralized blockchain the users will notice that and they have total freedom to not engage with the chain if they already have assets on their chain we have total freedom but in most cases to to withdraw and move on to somewhere else they prefer so I think options don't necessarily need to be decentralized as long as first is it's free to entry and exit anybody can spend spin up their own uh app chain right

that enters the market to compete with incumbents and that people have the freedom to choose which chain to use to engage so let's say there are many centralized chains in the ecosystem if users actually have a preference for decentralized ones then free market competition will naturally drive all the chains to be decentralized to attract users so that's why I think uh centralization of powers almost always bad in in nation states but not necessarily for actions yeah no I think I I agree with you on

some parts there um I think the one of the risks that I see is um you know capture a user's assets and censorship and things of that nature that can the the centralized chains um like work centralized change could perform an attack on their users that would make it difficult or or impossible for users to to leave to opt out at least without having suffered Financial uh loss um yeah I mean I I but but then I also agree on the fact that you know um that the free market will uh likely you know create

conditions where users like are are comfortable with like the degree of centralization in in app chains or decentralization or whatever like you know there will be some sort of like uh equilibrium across the ecosystem where you know if you want to use a more centralized service you can or if you want to use something else um you're also welcome to do that but yeah yeah I feel like there's a there's a whole other hour that we could like discuss the yeah one sentence I would say follow my logic if you really want to push for decentralization instead of pushing you each change by putting pressure on dev teams or validators like that we should really like focus on education

like if if we educate users to actually favor decentralized options over more centralized options the competition will naturally drive all the change to to be more decentralized right yeah I think that's the yeah that's the thing yeah I yeah I think I think you're right um that education is needed and education and awareness is what would drive users to want more decentralized chains um if the if the concern for privacy and web 2 has taught me anything is that users typically don't care about these things uh you know

uh most of the people I know are still using like Facebook messenger and WhatsApp and whatever and have not like uh you know moved in droves to use signal or other Alternatives even though they're better and they uh preserve their their freedoms and protect their privacy so is it different with blockchains I don't know you know if you've got like a really popular app that everybody is using but that thing is super centralized chances are people are going to want to use that thing uh until something goes wrong and um but yeah I yeah there's a there's a case to be made also I think for like why education is important like we always need to like keep educating right whether it's about privacy or or the the value of having actually like

decentralized governance and um and uh and block execution on Chains It's like super important and this is also one of the big reasons why I'm doing this podcast [Music] uh yeah Larry thanks so much thanks again for coming on and um yeah look forward to continuing this conversation on Twitter and maybe again here on the podcast at some point in the future and to our listeners thanks so much for tuning in we do live streams every Thursday if you'd like to be notified when I have new guests on please consider subscribing to the channel and uh also like this video and hit the notification Bell and you'll get notifications that are reeking also

follow me on Twitter I'm Seth 3.0 like right down here right here and yeah we'll see you next week thank you