Upgrade to cosmos-sdk v0.45.0

[alpe]

Resolves #501

This upgrade includes

• Upgrade to cosmos-sdk version v0.45.0
• Upgrade to new IBC version: v2.0.2
• Use 32 byte address length for contract addresses
• Replace msg.Route() based handlers with ADR 031 request type routing for contract messages
• Add feegrant module to demo app
• Add authz module to demo app

Follow ups:

• Should we add support for "feegrant" to cosmwasm?
• Should we add support for "authz" to cosmwasm?
• Should we integrate IBC version negotiation, Support IBC version negotiation in contracts wasmvm#269?
• Should we pass the IBC relayer address to the contract?
• Should we do the IBC receive package (n)ack error cases differently?

[codecov]

Codecov Report

Merging #717 (c160c30) into master (52477ea) will increase coverage by 0.77%.
The diff coverage is 72.43%.

@@            Coverage Diff             @@
##           master     #717      +/-   ##
==========================================
+ Coverage   59.21%   59.99%   +0.77%     
==========================================
  Files          48       48              
  Lines        5451     5592     +141     
==========================================
+ Hits         3228     3355     +127     
- Misses       1992     1995       +3     
- Partials      231      242      +11     

Impacted Files	Coverage Δ
app/test_access.go	0.00% <0.00%> (ø)
app/test_helpers.go	0.75% <0.00%> (-0.10%)	⬇️
x/wasm/client/cli/gov_tx.go	0.00% <0.00%> (ø)
x/wasm/keeper/api.go	42.85% <0.00%> (ø)
x/wasm/keeper/handler_plugin_encoders.go	80.88% <ø> (ø)
x/wasm/keeper/ibc.go	77.77% <ø> (ø)
x/wasm/keeper/query_plugins.go	79.47% <ø> (ø)
x/wasm/types/params.go	61.53% <ø> (ø)
x/wasm/keeper/querier.go	62.12% <33.33%> (ø)
x/wasm/types/keys.go	34.88% <50.00%> (ø)
... and 15 more

[ethanfrey]

Thank you @alpe for this PR.

Re the follow ups. This is a very important question before merging, or at least before tagging a release.

• Should we do the IBC receive package (n)ack error cases differently?

-> This is an important question we should work out in the design docs and make a decision there before implementing. This has been heavily discussed in #697 and changes were made to the wasmvm interface to expose all needed info to the runtime, but we need to document the behavior.

These ones would be nice to have by 1.0 but require extending the CosmWasm interfaces in a backwards compatible way:

• Should we add support for "feegrant" to cosmwasm?
• Should we add support for "authz" to cosmwasm?
• Should we integrate IBC version negotiation, Support IBC version negotiation in contracts wasmvm#269?
• Should we pass the IBC relayer address to the contract?

-> I added a tracking issue for this in CosmWasm CosmWasm/cosmwasm#1200 Please add more thoughts/comments on these to that issue

[ethanfrey]

@faddat @iramiller @ValarDragon @RiccardoM @litvintech

I would love any comments here as you all have been working on 0.44 forks.

[faddat]

Hi!

a moment to collect thoughts :)

• Should we add support for "feegrant" to cosmwasm?
  This would be handy, but probably is not strictly necessary.

Should we add support for "authz" to cosmwasm?
This would enable some really interesting contract use cases, and better security.

Should we integrate IBC version negotiation, Support IBC version negotiation in contracts wasmvm#269?

Should we pass the IBC relayer address to the contract?
I'm a reasonably large relayer, and I'm not sure what benefit that could bring -- in fact, it may be best to keep contracts unaware of who is doing the relaying since we (relayers) provide a generic service.

Should we do the IBC receive package (n)ack error cases differently?

[ethanfrey]

All of those require extensions to the CosmWasm interface.
I would get this in with the same API, and then work on those once we support them in CosmWasm (another release).
There is a linked tracking issue in CosmWasm to discuss this as well.

[ethanfrey]

Should we pass the IBC relayer address to the contract?

I'm a reasonably large relayer, and I'm not sure what benefit that could bring -- in fact, it may be best to keep contracts unaware of who is doing the relaying since we (relayers) provide a generic service.

This will be needed if we want to provide bonuses / fees / incentives to relayers in the future. It should not be used for auth

[ethanfrey]

Should we add support for "authz" to cosmwasm?

This would enable some really interesting contract use cases, and better security.

This would mean that you could say provide partial account access to a contract (like let it stake on your behalf). Happy if you have more practical ideas here.

But will take this into account as a wished feature, just need to clarify it

[ethanfrey]

Unless anyone has concerns, I feel this is good to merge

[ethanfrey]

good stuff

[tomtau]

Suggested change

	github.com/cosmos/cosmos-sdk => github.com/cosmos/cosmos-sdk v0.45.0-rc1
	github.com/cosmos/cosmos-sdk => github.com/cosmos/cosmos-sdk v0.45.0

[ethanfrey]

@alpe why is this even here?
github.com/cosmos/cosmos-sdk v0.45.0 is set above and we don't change repos.

I would remove it

[tomtau]

I think it's because of ibc-go which may be bringing in a different version of cosmos-sdk

[ethanfrey]

Turns out they were added here: https://github.com/CosmWasm/wasmd/pull/692/files

With a recent comment they are not a good idea: #692 (comment)

I fixed them with your hint, but maybe they need to be removed as well....

[alpe]

ja, a transitive dependency. I did not look where it came from but just wanted to ensure we have the right sdk version set.

[ethanfrey]

good point

[ethanfrey]

@alpe why is this even here?
github.com/cosmos/cosmos-sdk v0.45.0 is set above and we don't change repos.

I would remove it

[alpe]

lgtm 🎉