I’ve spent a few days thinking about this and I tend to agree. Having closed source contracts, while in some cases might be useful - should be avoided, at least in the short to medium term.
Having a situtation where a closed source contract runs away with peoples funds would not be a good look for the hub. However the only way this can really be prevented is by education and informing validators and delegators before and during voting periods on indivudal proposals.
Anoter signal proposal could be passed to show intent from the community to disuade closed source projects from even attempting to get their dapp listed on the hub.
The hub needs to do what is in its best interests, which is to adapt and evolve.
ICS is great, but it’s not unique and might not be the best way to make a ‘hub’ on the interchain.
For that, we need to ensure other chains see it as a hub, and having an ‘Apple store’ of trusted dapps at the center is the best way towards that goal.
Neutron is just one of many smart contract chains, and sadly atom holders don’t even have a significant stake in its success.
However having permissioned dapps on the hub opens a new world of possibilities to interface with permissionless dapps on these other chains. It really levels up the potential, which will draw in new users from outside the Cosmos as a whole.
This isn’t about any one dapp being deployed to the hub. It’s more of a proclamation by the ATOM community that we envision a paradigm shift whereby the Cosmos Hub reclaims its title as hub of the interchain.
The best way to acheive this is to enable permissioned wasm so that developers and chains know they can submit their best dapps to the “Apple store” of the interchain, a place where only the highest quality and trusted applications live.
It’s also not a good idea to combine the submission of a dapp with the proposal to enable wasm. Voting should be done on one thing at a time, and while the community might agree on deploying permissioned wasm as a whole, they might not agree with the dapp that is being bundled with it.
Last year, Prop 69 to add CosmWasm was rejected. I think a big part of the reason was that there wasn’t a good argument for adding it. No killer app.
While I personally support CosmWasm being on the Hub, I wouldn’t want to see a prop similar to prop 69, with no killer app, being rejected. This would set a precedent of CosmWasm having been rejected not only once, but twice. I’d be worried that this would then make it hard to get it approved when we need it for mesh security.
So I share your goals, but I think politically, it might be better to first have a vote on whether the community supports CosmWasm to run Mesh Security, then move on to opening it up to a larger set of applications.
I’m personally of the opinion that the main reason prop 69 failed was because one of the founders of Cosmos (Jae Kwon) offered an airdrop to users that voted No/No with Veto.
I am in support of CosmWasm on the Hub in order to have mesh security, which I believe is important because it strengthens replicated security and enables the Hub to form meaningful relationships and alignment with other non-AEZ chains.
However, I would vote no on the proposal in its current form (despite my support for CosmWasm on the Hub for Mesh Security) on the basis of it not including a risk analysis, implementation details, scope, and other important details that need to be considered for any technical change on the Hub.
I’m also opposed to the idea of the Hub as an “app store”, and would like to see an explicitly stated scope for CosmWasm at the outset.
Actually this is precisely what I want to comment on.
Noes:
I do not want CW defi apps on the hub.
I do not want closed source anything on the hub ever. But I do want to be specific, BSL and other source available licenses are totally cool with me. I want to praise Larry for championing this cause throughout Cosmos, his approach has proven to be extremely rational.
I do not want the hub to undermine Neutron.
I do not want the hub to be an application platform.
I do not care about roll-ups originating on the hub. They can originate on a consumer chain.
I do not want cgo type conversion messes on the hub or anywhere in Cosmos.
For more info on elimination of CGO type conversion messes all across cosmos, please see this document that our team has been preparing with the cyber community (@serejandmyself ) and please know that it might be accomplishable in one bold sprint but we have failed at that several times so far.
What I am asserting is that CGO extremely bloats up the resource usage properties of CosmWasm. I know that @ethanfrey and the team at confu disagrees with this, but nonetheless I do believe I’m correct and there is really a tremendous amount of evidence that CGO is a total anti-pattern when writing code in go and that that it would be better, safer, clearer and simpler to replace wasmer with wazero.
The cyber Blockchain community has agreed to sponsor one full-time engineer on this task, once that chain has been brought up to date with the latest SDK features. So in that case I suppose that we would be moving on that in about 3 months. In addition to that, we are happy to discuss this initiative with grants programs, as it may be beneficial to add additional engineers to the wazero initiative.
I wish to repeat once again that CGO results in dramatic increases in RAM consumption and harms go’s native type system, leading to situations that are prone to error.
Results are NOT guaranteed!
This change to CW would be fairly fundamental and is challenging, and we might get it done in one big push or it may never happen, we have discussed this extensively with cyber, but I just want to make it extremely clear to the community that we cannot be certain that this initiative will be successful.
(That said I really do want the hub totally free of CGO. I do not trust cgo. It gives me bad vibes man)
Yeses
I want mesh security on the hub.
Mesh in go is best
Mesh in cw with wazero is better
If needed I will absolutely 100% support mesh only cw on the hub.
Notional will veto proposals to do more than mesh on the hub, including:
Daodao: it can go on neutron. Hub can use groups. Hub was never meant to be featureful.
Anything other than mesh
I agree, and I would limit the scope to mesh only. In fact I will be vetoing proposals that do anything else.
Hi there Tom, I’m going to give you my understanding of the situation. Everybody wants some mesh in go, and in general it looks like we’re trying to make cosmos bisexual in rust and go, and I think that’s great idea, however I would like to note for you that it is likely to take a good deal more time to make the bisexual version of mesh, which I why I created the bulleted list of preferences above.
Yeses
I want mesh security on the hub.
Mesh in go is best
Mesh in cw with wazero is better
If needed I will absolutely 100% support mesh only cw on the hub.
Notional will veto proposals to do more than mesh on the hub, including:
Daodao: it can go on neutron. Hub can use groups. Hub was never meant to be featureful.
Anything other than mesh
I am also stating my willingness to work very hard politically to ensure that mesh gets on the hub and in a timely fashion.
The other stuff very much should go on neutron or another consumer chain, depending on the purpose of the contract.
If we want a scope limited hub, and I do, that means limiting scope :).
about ICS 2 and 3
@tom I believe that there is feature overlap, but there is not protocol level compatibility. I also think that it would be super to get @jtremback’s current freshest opinion on the matter.
Notional will veto any attempt to make this happen.
I agree
The hub is not osmosis, and the hub should not aim to be osmosis, it should aim to be the freaking hub.
Of course, if governance chooses this direction, notional will support it, however I wish to state strongly and directly that notional will veto non-scope-restricted to mesh only, with full source availability stipulations attempts to put cw on the hub.
This is not the narrative that we have adopted in the ICS paradigm, and it is not the narrative that the hub’s governance has chosen.
If esteemed colleagues in hubland like @jtremback, @ebuchman, @mpoke and others who concern themselves with the primary engineering interests of the hub, feel that we should CW it up in order to mesh it up, notional will support this effort. Our decision on any given governance proposal will be made after a consultation with all of these people, noting that unanimity is not required.
I think that ICS is a uniquely good shared security approach. If we compare it to what is available on dotsama, for example, its design superiority rings true in a glorious manner.
Having a full comfort with open governance, also means having a full comfort with anyone, including @CosmosChain, making any proposal that they wish to, even if it were to radically change the direction of the hub.
With that said, I do not support this proposal in its current form, due to its lack of scope restriction and stipulations on source availability.
As a validator, I wish to tell you that while it is absolutely true that the hub is now more expensive to operate I also wish to tell you that the increase in expense is to some extent no big deal.
I was fully aware that the economic models for ICS were immature, and I supported them anyway, because I knew that ICS was a fundamental improvement in the state of technology in the shared security realm, and due to my knowledge that we could always negotiate with consumer chains post launch. Validators complaining loudly about cost of operating the hub should be making proposals that fix that.
While I did reject the initial research on the economics of ICS because it had not been put into production, my vote to put it in production was aimed at gathering the actual data needed to figure out how to build economies around ICS.
I am in total opposition to this sentiment, and will veto proposals espousing this sentiment.
Oh I really love this one so much. Thank you for these comments.
I’m not really sure that the current state of technology allows us to have a constitution that is not just as mutable as any other governance decision.
The hub has already funded confio for their work, and I wish to note that notional voted Yes on this decision due to the fact that confio excels in their work.
I do not think that we need any kind of a permissioning DAO. I think that full scope restriction to mesh only is the correct way to proceed, if at all.
You literally just said that you want to throw neutron under the bus. AEZ will not evolve into a great thing if we begin to throw consumer chains under the bus. In addition to that, using permissionless CW is so much easier.
Therefore I wish to declare that in its current form, I will veto this proposal due to a lack of scope restriction yeilding a spam gov prop via the “informal 791 precedent”. Fat gaia is already fat without CosmWasm and cgo.
like informal did in prop 791, I shall loosely define spam and veto this as spam cause I don’t like it. Because what is spam other than stuff people don’t like?
Please note that it will suddenly not become spam if it is scope restricted to mesh only and includes source availability restrictions.
Interesting how that works.
I apologize to anyone who may feel offended by “fat Gaia” terminology. I will continue to use such terminology unless of course I am provided with an even more effective metaphor:
I will formally use the fat Gaia terminology for the duration of discussions on CosmWasm on the hub as I believe that metaphor to be highly effective in promoting an understanding of feature bloat. I have been unable to find equally effective metaphors.
To @lexa I understand your objections to this terminology, and if you are able to suggest better terminology, I will adopt it after market testing it.
This would include eliminating all usage of the fat Gaia metaphor in perpetuity and from past posts.
The trouble is I have not found something that people understand as readily as that metaphor.
Thus this is a request for help in that matter. Thank you.
Eg: I cannot sacrifice effectiveness in speech. But if I get help enhancing that, I assure you, I will accept and adopt that help.
I think the Cosmos Hub has for too long been afraid to compete to be the center of actual activity.
You mention Neutron (one of many potential ICS chains that could provide unrestricted applications), which has only given atom holders 12% of the token share, which leaves founders (23%) + early backers/vcs (11%) to have 34%. By agreeing to not have features that ICS chains can do puts the Hub in a situation where it is dependant on what ICS can generate, which with fees etc might be insignificant for a long time period. I’m not even suggesting the Hub becomes a place for unrestricted dApps, just those that ATOM delegators determine are good enough to embrace into the Hub.
These top tier applications can then be marketed to investors in other chains, while right now there is no real way to associate Cosmos the brand with these techniogical achiements since they exist on so many different chains derived from the Hub.
The Hub needs liquidity directly onchain to become the actual hub. Remember, ICS chains can always eventually leave ICS and become sovereign, and if ATOM holders don’t own a significant share of the tokens then what was the point?
The hub has already encountered this dilemma before… is the hub a hub if IBC doesn’t necessitate a hub? Is the hub just one of many hubs if it’s not the center of the entire interchain, IBC included. A trusted dApp store at the center of the interchain would make the hub the ‘hub’, where all activity and transactions would flow through.
Finally, I think using no with veto on legitimate proposals can lead to a chilling effect on new ideas This is because people might fear the risk of losing their funds, so would not risk proposing certain ideas.
I appreciate the shout out and wordsmithing session!
I have to admit that you’re probably not going to find a more marketable figure of speech. In our industry with our audience (which is severely lacking in women, who tend to be the ones most exposed to fat-shaming and diet culture although certainly not the only ones affected), I can understand that the marketability of that phrase outweighs the discomfort I pointed out. I get it, even though it makes me wince.
For an analogy for ‘feature bloat’ that avoids gender (‘Gaia’ as a woman) or fat-shaming, my mind goes to a congested transit system or bus (anyone taking public transit at rush hour in the summer may sympathize).
I think of all the features on the Hub as individuals who are trying to make their way in the nexus that the Hub provides - they’re active and they have their own motivations and goals that sometimes come at the benefit or expense of the Hub itself.
I think we’re not quite there with crowded bus, but I wanted to recognize that you had a totally legitimate criticism, and hopefully figure out a better way to communicate this.
It’s not precisely a crowded bus or a fat person.
During proposal 69, I had a less complete understanding of the issue.
Have you ever looked at the type conversions in WASM VM by any chance?
While previously I would have cited resource consumption as the primary issue, it’s the type conversions and the use of CGO, which I now believe is the primary issue, driving problems with both gas metering and resource consumption.
I agree with you and that is why I believe that we should remove the abstain and veto options.
Veto should not be removed from every gov proposal, just every gov proposal type except for software upgrade and client update proposals.
The reality is that we would not represent our delegators as if effectively as possible, if we did not adopt the prevailing definition of veto, which is, per 791 – sth I don’t like.
That’s actually why I do believe we need to just remove those options. Generally, abstain at this point is more of a virtue signaling mechanism for non-participatory validators.
I wish to make clear that it’s not as though you don’t raise valid points.
I guess that the way I’m feeling about this is that ICS has really been very successful. There is a a category of chain that thrives on having additional economic security.
I suppose that maybe the biggest difference in our points of view, is it from where I am standing ICS is an absolute home run.
I agree with you about revenue for the hub, it is not high enough.
I will explain to you what drove my decision making a round revenue in the early state. Basically, neutron and stride both took truly outsized risks. I wasn’t terribly concerned with the economics because I felt that, and I still feel that it is possible to negotiate those in the present day.
It was from proposal 69, he accused supporters of wanting to turn the hub into “a shitty version of Ethereum” – how to avoid, always felt he was correct.
If it is just default state permissioned CW, then I do believe that the hub becomes an unrestricted place for applications. My reasoning is first of all that there will be more and more applications on the hub, I realized that you are seeing that as a good thing, I am very much not so sure .
Secondly I do believe that it leads to the situation where the hub almost inevitably becomes a permission list CW chain, because frankly permissioned cw is a total pain in the ass to work with.
Thirdly I do have an idea although I do not think you will like it, another way to prevent the proliferation of contracts onto the hub but get mesh security, would be to simply remove the various mechanisms for adding contracts to the chain beyond the very first one, which of course should be mesh security. Now it’s true that those could easily be replaced but it would show a great deal of intent.
Here’s my last item, because I think that it is important to try to understand all sides of an issue in order to argue productively, so I am going to attempt to summarize your position as succinctly as possible:
@CosmosChain feels that enabling permissioned CW on the cosmos hub will allow for the hub community to capture greater value than the current ICS model.
Please let me know if you think that I got that wrong at all, and please also know that you are appreciated as always Mr roller coaster.
My comment on CW as an SDK module not being a good option comes from a direct conversation @jtremback and myself had a few months ago where he was telling me this exact thing.
Just saw you edited the post, I was about to say I didn’t appreciate the tone of your message but we’re good now
it’s fair, and probably right i don’t know. from what i see/saw there are different takes and perspectives about this,
maybe it’s not cool with ICS v1.5/2?
if there is some sort of consensus around “clearly not the right way” (i may have missed this) i would respect - again not dunking i felt it was a definitive non-option ?
happy to learn more overwise
(ps: je dois faire des phrases étranges en anglais aussi et ouai je suis sec parfois pas de méchanceté en tout cas)
I don’t think that waiting for some hypothetical and currently non existent Go implementation of Mesh Security is a great idea, because I don’t want to see the Hub stuck on a weird alternate version of Mesh that nobody else uses.
I personally don’t have strong feelings about the idea of doing other CosmWasm apps on the Hub one way or the other. It seems like it would be pretty easy to disable the uploading of contracts other than mesh security, but personally it seems like people could just vote against contract upload props if they don’t want them.
)
et ouai je suis sec parfois pas de méchanceté en tout cas)