Thanks Billy for the thoughtful initial writeup and everyone else for the discussion. I have a few thoughts on this. My general feeling right now is to vote No, but I will try to provide some analysis around what I think would be needed for a Yes.
I could imagine a VM going on the Hub, but I would expect it at least to (1) have a dedicated team of trained experts in that VM and its integrations, focused specifically on its deployment on the Hub, (2) have them engage in or oversee a focused security review, (3) have them provide clear reasoning why it should be directly on the Hub vs on an interchain secured consumer chain, and (4) have them integrated into the governance gated deployment process. I don’t think we will have that by Q2 2022. We do want to have a team like that to support CosmWasm consumer chains anyways, so we are working on building it up. So I guess it’s a question of timing.
That said, my general preference is for the Hub to lean towards minimalism. A big part of why we’re building Interchain Security is to enable the Hub to extend its functionality in a principled way, using the age-old principle of process isolation to scale computation. Ideally, I think VMs like CosmWasm should run on consumer chains secured by the Hub, rather than on the Hub itself.
Of course, it will take additional engineering effort to achieve this. Process isolation comes with additional overhead - it makes communication more complicated. Instead of a local function call, you’re doing RPC. The code has to handle more failure modes and edge cases. The IBC programming model is still quite young, and we don’t have an IBC query system yet (though it’s being worked on), which is needed for consumer chains to be able to read data from the Hub and vice-versa. Interchain Security also isn’t ready yet, and won’t be by the Rho upgrade (though it should be by later this year!). So again, this proposal is really a problem of timing.
The sense of urgency seems to be coming primarily from liquid staking. In my understanding, liquid staking is important at least because it allows the Hub to natively provide what centralized exchanges are already providing (ie. ATOM derivatives), and thus push back against centralization of voting power in the exchanges. The flip side is of course a new centralization of voting power in the liquid staking providers. In general we should probably be looking at additional ways to decentralize voting power, but liquid staking might be able to help. It does have its own risks, so we need to be careful, and set some kinds of limits, and nurture competition between providers.
The core liquid staking module provides a simple primitive that others can use to build proper staking derivative products. But without CosmWasm on the Hub or Interchain Security, such products will have to be built on external chains, which introduces its own security concerns. Ideally, the core ATOM staking derivatives are secured by the ATOM validator set. In my understanding, Quicksilver and Lido both plan to build ATOM staking derivative products secured by the ATOM validators. Quicksilver plans to build a consumer chain, but they may launch a sovereign chain first (whether or not the native liquid staking module is live) and then convert to a consumer chain once interchain security is available. Lido plans to use CosmWasm on the Hub, but ideally with Interchain Security they could use CosmWasm on a consumer chain. Of course building staking derivatives with CosmWasm directly on the Hub will at first be easier than building it using a consumer chain, as mentioned above (the difference between native function calls and RPC). But as the IBC programming model matures, this should become increasingly seamless, and probably preferable.
In any case, I think this means the launch of the liquid staking module needs to be accompanied by CosmWasm on the Hub or by Interchain Security so that staking derivative products are secured by Hub validators. Whether or not external chains should be able to provide staking derivatives using the native liquid staking primitive is another question. But if CosmWasm is rejected from Rho, it may not make sense to include liquid staking in Rho either. I’m not sure if that dependency is totally clear in the discussion.
So it’s basically a question of how urgent liquid staking is. My general bias is towards moving slowly and deliberately and trying to follow consistent principles, but I recognize that can have significant tradeoffs in the product market process. That said, past features developed for the Hub (Gravity DeX, Gravity Bridge), have had their own product market issues. CosmWasm has the potential to be much more successful in positioning the Hub more competitively until (or even when) Interchain Staking is live (beyond just liquid staking), but it may also compromise the Hub’s reputational position of being more minimalist and thus more stable, reliable, etc. I understand some feel the utility of that minimalism has yet to prove itself, because it can inhibit the Hub from competing on the shorter time horizons of hot money flows. But the whole point is to build for the long-term, to be an anchor in a thrashing sea. And with recent growth in development teams focused on the Cosmos Hub across core Cosmos organizations, velocity on the long-term roadmap is picking up.
Lastly, some meta comments on governance. While there has been plenty of general discussion about CosmWasm on the Hub in various channels, it seems there was not a significant amount of explicit consensus building done off-chain before this went live - this forum post had little activity until the proposal was on-chain. Ideally, by the time a proposal goes on chain, stakeholders are generally aligned about a positive outcome. Maybe some kind of pre-voting mechanism on the forum would help. Of course it won’t always be possible to build consensus before going on-chain, especially when there are strong conflicting views. And the present case is unfortunately further complicated by Jae (who has not played any kind of meaningful role in Cosmos development for years) effectively bribing people with the Gnoland airdrop to vote a particular way, which showcases current weaknesses in the governance system. Hopefully in the future we can move towards some kind of privacy preserving voting system and in general work on better governance norms and mechanisms to mitigate these kinds of attacks.
In the end, it seems like this proposal has spurred a lot of healthy debate and it’s exciting to see so many people engaged who care about defining the future of the Hub. Looking forward to continuing to build and evolve this thing with all of you, regardless of this proposal’s outcome