CosmWasm / wasmvm

Go bindings to the running cosmwasm contracts with wasmer
Apache License 2.0
173 stars 99 forks source link

feat: QOL GetDefaultFeatures #413

Closed Reecepbcups closed 1 year ago

Reecepbcups commented 1 year ago

Feature

It would be nice to have wasmvm.GetDefaultFeatures() to return the default features. This is also used in the internal test.

Reason

When upgrading, its common to forget this ( We did for juno v14). It would be nice for this to be upstream to ensure its handled when chains upgrade their wasmvm automatically for future 1.3+ wasmvm new features

Before & After

app.go image

webmaster128 commented 1 year ago

Hmm, it's here but only as an example, not a default value: https://github.com/CosmWasm/wasmd/blob/v0.31.0/app/app.go#L517. There should be a default which you can expand.

Reecepbcups commented 1 year ago

There is no such thing as default capabilities in wasmvm. The chain using wasmvm need to support this the features. If I added fobar here but the chain does not support it, an wasmvm upgrade would break things.

If we add it, it should be done in wasmd. Wasmd already maintains such a list.

my idea here is that each wasmvm version as upgraded, would then add the cosmwasm1# to this. Then wasmd would call this like you mentioned with https://github.com/CosmWasm/wasmd/blob/v0.31.0/app/app.go#L517

(Since cosmwasm_1_2 is in reference to wasmvm, I really feel it makes sense to add here?)

Then in wasmd you would do

availableCapabilities := "iterator,staking,stargate," + wasmvm.GetDefaultCapabilities(). Then as versions increase for wasmvm, they auto persist to wasmd & the upstream chain?

yay / nay?

webmaster128 commented 1 year ago

nay, capabilities are always negotiated between chain and contract