Open letter to the cosmos community
Hi this is Jacob you may know me from my Twitter account Twitter.com/gadikian and others of you may know me from my GitHub account, faddat.
Some of you might not know me at all and that’s fine too I hope you’re doing well. All right so I really want to lay a few points hopefully as clear as possible concerning the recent discussion about cosmwasm on the hub and my experience with cosmwasm and I’m going to try to keep it absolutely as plain and boring and technical as possible.
I basically have the role that I currently have in Cosmos because of various mentors that I’ve had, and these people include Jae Kwon, Jack Zampolin, dev, Alessio, and to be real, countless others. I have been known to have great appreciation for Zaki’s one-liners. Not one liners as in bash script, but his statements that compile huge amounts of knowledge into a single sentence. It’s impressive. It was Jae who initially pulled me in in 2016, and it was Jack who taught me IBC.
I want to have a Frank an open conversation about CW on The hub because I’m not exactly opposed to it in the same way that my teacher Jae is, but he makes some valid points and these get lost in the Twitter noise. Furthermore, Jack, Billy, Zaki, are all making valid points as well and they are getting lost in the Twitter noise as well. So I decided to write long form even though I really do prefer to communicate in tweets.
I’m really happy to work in Cosmos. Honestly it’s probably the only place that a freak of my level could work at the level that I’m working and I really really enjoy it. If anybody is reading this and wondering if they should get involved, if they like to express themselves using software then Cosmos is probably a very good place to do that. I guess that the way that things are looking right now GNO is not going to be Cosmos but you know what I’m very interested in that too.
I don’t think that the Cosmos hub is going to die without CW. Part of me did not like the veto vote that I put on Billy’s recent governance proposal because it was a technicality, I was a no. But at notional labs we have come up with a way of carefully going through governance proposals, very specifically we look first at the software and then we look at the accumulated set of governance proposals over time. What this gives us is a more or less objective way to judge governance proposals.
The veto was used specifically because the description text on the veto option did not match what veto actually does. Here is what veto actually does, if we use the notional labs method for determining the purpose of veto well what we can find is that Cosmos hub proposal 6 proposed by the Sikka labs team defines no with veto as follows:
https://ipfs.io/ipfs/QmRtR7qkeaZCpCzHDwHgJeJAZdTrbmHLxFDYXhw7RoF1pp
We instead propose that the deposit be returned on failed votes, and that the deposit only be burned on vetoed votes. If a proposal seems to be spam or is deemed to have caused a negative externality to Cosmos communninty, voters should vote NoWithVeto on the proposal. If >33% of the stake chooses to Veto a proposal, the deposits will then be burned. However, if a proposal gets rejected without being vetoed, the deposits should be returned to the depositors. This proposal does not make any change to the current behavior for proposals that fail to meet quorum; if a proposal fails to meet quorum its deposit will be burned.
Okay so what we can see there, is that the way that Billy defined no with veto in 69, is simply not what it does and it’s my personal opinion that freestyling governance options is a path to harm. Much more serious than the type of harm that could occur if we put CW on the hub by the way. So I vetoed because the description did not match either the code or the previous proposals.
Now, this gets technical and there’s nuance, please, for my own sake and for the community’s sake please hear me out here.
The hub lacks any clear definition of itself. Because of this I do not have the same issues that Jae does concerning cw on the hub. I realize that he has a vision surrounding the hub and that his vision differs from other people’s vision. But did you know that I wrote the readme file for the cosmos hub? Yes others have since rewrote it but at one point I wrote it because I thought it really wasn’t good enough.
When I wrote it I made really sure to mention that it was a cosmos hub not the cosmos hub. Currently I suppose that it is the cosmos hub but let’s be real there are a huge number of chains that began with Gaia’s code base. These include to the best of my knowledge osmosis, ki, every single starport scaffolded chain until the introduction of SPM and CosmosCMD, we owe that fat lady a lot in fact I think that we owe her the best possible treatment .
So one of the things that I’m going to hold really steadfast to is that notional would execute what I mean is we would operate, a governance mandated implementation of CW. Because the chain lacks any constitution or mechanism banning it, we absolutely would accept governance decisions that implement CW. But at this time we would not vote for them and I’m really trying my best to sort the concrete facts from the noise because all of us including me generate some noise on Twitter.
Facts:
- Validating CW chains on arm is untested but maybe possible and we may be the ones to test it
- Terra did not die while being attacked and that’s kind of a big deal
- Chains that implement CW do seem to exhibit some strange block miss patterns, but these seem to be resolved in the latest versions of CW and I don’t know for sure if those are related to the Cosmos SDK or tendermint or CW itself because when we change the version of CW we also change the versions of the supporting libraries
- All of the performance problems that I am aware of, and they are numerous, can be traced back to the database layer + IAVL which we use to enforce the determinism that IBC relies on.
- CW has enormous potential and it could replace in many cases the functionality that is expected from other layers of software, for example shared security.
- Both sides of this argument really do not give one another enough credit and I don’t know how to purge the bad blood and I’m intentionally putting this in the facts category I have suggested and I continue to suggest a Bitcoin mine shipping container cage fight but there could be ethical problems with that approach, and furthermore we do have governance so that we can make decisions.
- There are real risks to CW but this really is not the most risk-averse business, now is it?
Opinions:
- In general, I think that we should build chains with glibc not muslc, especially in ci.
- I’m pretty sure this is why we have forks
Okay so I really like the auditability found in GNO. In my opinion that is some next level stuff. I think that the licensing needs to be worked on to some degree but I think that’s a solvable problem and Lord knows that I have written my own licenses before.
If there’s a problem with the Juno airdrop it’s probably one that’s a little bit counterintuitive, specifically that we did not include centralized exchanges. Ouch, right?
On the cosmos hub front, what we can see is that the hub is kind of an IO port for the finances of the entire cosmos ecosystem. That’s really incredibly important. And I think that 100% of the actors involved in the conversation understand that it’s a critical piece of infrastructure. On the pro CW side, I would say that they’re looking for native CW capabilities directly on the hub where we go in and out of Cosmos because we can create genuinely new and interesting things. By the way, I agree but nonetheless voted no with veto, and would have still voted no on the technology.
Once again, I’m confronted with reality that a fork seems to be the best possible way forward.
Recently I tried to deploy CW contracts onto osmosis and I would like to make clear that I found the governance gating procedure truly painful. I was going to spend more time deploying those contracts onto osmosis than it would take for me to put them together. As one of the early authors of Juno and her current team member of Juno, I also need to say that one of the truly great things that Juno is doing for the ecosystem is absorbing the risk of permissionless IBC enabled cw contract deployment.
Next possible steps
Let’s just say that I found dealing with governance gating to be really unpleasant. I think that one option is a consumer chain, that is a blockchain that uses the security provided by the cosmos hub, to provide an unpermissioned CosmWasm environment. But this has legitimate disadvantages. Probably first and foremost among these disadvantages is that this chain while we can speak speak of it as asynchronous. That means that it does not operate in tune, in sync with the hub. Deploying CosmWasm on the hub directly does have some real advantages.
But there was another poster here, who had the gall, and I am an appreciator of gall, to state that there was a risk of the hub turning into a shitty version of Ethereum. I’ve got to agree with that guy.
You’ll note that I’m describing this as a risk and not a certainty. I don’t know what would happen if we put CW on the hub, I think that no one does. Billy is right when he says that CW would allow for faster code deployment and faster evolution of the code base, kudos to you for that Billy.
I really want to keep this conversation in the realm of confirmable fact only. So if we take all of this information and we try to distill it, it is my firm belief that our best option is to create a second chain with exactly the same token holder scenario as the cosmos hub and then put permission to or unpermission CW on it .
But we really should discuss the competitive issues that are inherent to this because there are many. So first of all, I recently noticed that Sunny had mentioned putting unpermissioned CW on osmosis. Okay so all of the sudden we have created a competitive threat to Juno and we can say that maybe Juno loses its exclusivity as the place to do unpermission to CW in Cosmos. But let’s go deeper, osmosis is implementing code that ensures that CW20 is not needed, instead everything is SDK.coins. oh this is much much better really, and I guess I would just like to see that upstreamed. I don’t know if Juno would or could adopt it and also I think that there are probably second order implications of the lack of wrapping that maybe I’m not qualified to address although I’m learning contract code just as fast as I possibly can.
I do think that we should try to inherit as little as possible from ethereum. Over the years they have had so many security problems and I think that so many of those security problems are kind of endemic, they’re not the things that can be solved and so to the greatest degree of possible we should always try to create our own standards and then follow them. SDK.coins is a good pattern.
I validate the hub and Juno and osmosis and this actually creates some very real conflicts of interest. Basically, my economic interests are best served when all of those chains prosper. Part of this means compatibility. I really want for the contract standards that we deploy to be compatible. I don’t know if the SDK.coins version of CW found on osmosis will end up being properly IBC compatible with the CW20 version of CW found on Juno This is a serious concern to me. I have not done the needed code review yet and if anybody has insight on this I certainly request it.
So basically I suspect that it makes a lot of sense to fork the hub. I said this earlier, and then I sort of back down from my conviction on it but the reality is I think that that is the safest path because we end up with a plain hub and a very safe io port and we can keep that listed in the same places and it can continue to do its job and we end up with a CW hub that adds CW. Whether or not that’s the SDK.coins implementation or the CW20 implementation doesn’t matter a whole lot to me but I think that we should try for full ecosystem compatibility because please thank you so much for reading so long get ready for the next section.
The big deal
Hey guys it’s a big deal and although we printed a big old l with Terra recently, the reality is we are doing amazing and growing in this crazy exponential or even geometric pattern that reflects the design of the internet itself. Everybody every founder, every code contributor every relayer and every validator should be proud of their work. In my opinion our current state is a very low probability outcome and I think that The Cosmos SDK is kind of beginning to resemble Linux kernel development but we have no Linus because he left. But I have heard that Linus does both good and bad things and so now we all have to be Linus.
I know that not everybody knows this, but we are building a compute mesh. I want to see GNO play nicely with CW, and that doesn’t even get into the contract standard created by the brain fellows at agoric.
The smart contracts are just tiny little programs and they can grow in scale and scope pretty much to the same degree as the blockchains themselves and I think that this goes for any of the new contract standards that are being played with in the cosmos ecosystem. I don’t want to lose focus on the miracle of IBC.
I don’t choose my words lightly either, I say miracle because it’s just such a low probability event. It probably shouldn’t have worked the budgets were always too small, and I am very well aware that many individuals and organizations, including what’s now known as ignite, informal systems, the interchain foundation, The osmosis team, our community members, our relayers, our validators, have all contributed to that outcome. In order for that outcome to continue and evolve we need to focus on compatibility. I think there’s a case for redundancy here and that’s why I brought up the fork once again. If I had to guess all of the exchanges would be happy to list a CW enabled hub provided of course that their users received the airdrop, and if I had to guess this would give us a more resilient structure. What the hub has right now that no other chain does is extremely wide listing on centralized exchanges. And you know what guys? That’s awesome.
I know that we like to hate on the centralized exchanges but I need to dial in the message a little bit. I recently reviewed a governance proposal from Huobi. That’s right on the evmos chain they’re going to actually participate in governance. If you know me and you understand my stances you probably know that that has changed my opinion of their interactions with the ecosystem overall. Governance is our way of doing things.
Bullet point summary
- I think we should fork the hub
- I think agoric contracts should work to interact with cw and gno and vice versa. Our goal should be compatibility.
- I voted no because I’m aware of some technological issues, and I voted no with veto on a procedural technicality.
- Cosmos is a uniquely good platform for developers to express themselves using code and we should strive to preserve compatibility wherever we can.
- I wrote this document because I saw unimportant matters being discussed on Twitter when we need to focus.
- I have come to the conclusion that I do not support native cw on GitHub - cosmos/gaia: Cosmos Hub – now or in the future. I think that it would be very reasonable to fork Gaia to support those features, however.
