Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat!: integrate cosmwasm #3051

Open
wants to merge 26 commits into
base: main
Choose a base branch
from

Conversation

Reecepbcups
Copy link
Member

@Reecepbcups Reecepbcups commented Apr 9, 2024

ref: #3050

Adds CosmWasm and makes it permissioned in the upgrade handler per proposal 895 signaling to add.

Test Local node Script

# The testnode here is permissionless. On upgrade handler, permissioned is set
GAIAD_NODE=http://localhost:26657
rm -rf ~/.gaia/ && make install
sh contrib/single-node.sh local-1 cosmos10r39fueph9fq7a6lgswu4zdsg8t3gxlqvvvyvn

Upload Wasm Contract

sh ./contrib/upload-contract.sh

Local Upgrade

go install github.com/cosmos/cosmos-sdk/cosmovisor/cmd/cosmovisor@latest
GAIAD_NODE=http://localhost:26657

git checkout v15.1.0
make build
cp ./build/gaiad ./build/gaiadold
go clean -modcache

git checkout wasmd-integration
make build
cp ./build/gaiad ./build/gaiadnew

./contrib/scripts/upgrade_test_scripts/run_gaia.sh

./contrib/scripts/upgrade_test_scripts/run_upgrade_commands.sh 15

./contrib/scripts/upgrade_test_scripts/test_upgrade.sh 20 5 16 localhost

gaiad q wasm params

TODO:

  • Fix Upgrade CI (which works locally)
  • Changelog

image

@Reecepbcups Reecepbcups changed the title feat!: integrate wasmd into gaia feat!: integrate wasmd Apr 9, 2024
@Reecepbcups Reecepbcups changed the title feat!: integrate wasmd feat!: integrate cosmwasm Apr 9, 2024
Comment on lines 94 to 96
wasmParams.CodeUploadAccess = wasmtypes.AllowNobody
// TODO(reece): only allow specific addresses to instantiate contracts or anyone with AccessTypeEverybody?
wasmParams.InstantiateDefaultPermission = wasmtypes.AccessTypeAnyOfAddresses
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Need input on the team for if this. Should it be

  • InstantiateDefaultPermission = AccessTypeAnyOfAddresses (whitelisted wallets can instantiate new contracts as much as they want off of approve code ids from gov)
  • or InstantiateDefaultPermission = AccessTypeNobody (only gov only can create contracts off previously gov approved code)

To me AccessTypeAnyOfAddresses makes sense.

Copy link
Contributor

@MSalopek MSalopek May 27, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We want the governance to handle both code upload and instantiation.

IIUC, to use permissiond wasm we would need to use these settings:

wasmParams := wasmtypes.Params{
	CodeUploadAccess:             wasmtypes.AllowNobody,
	InstantiateDefaultPermission: wasmtypes.AllowNobody,
}

I don't think that code upload is followed by an instantiation operation by default. But, that can be can be achieved through a gov prop that has 2 Txs to execute: [MsgStoreCode, MsgInstantiateContract]. This way, the uploaded contracts would immediately get instantiated.

We can use MsgStoreAndInstantiateContract to store and instantiate a contract via gov proposal.

Do you have any comments on this @Reecepbcups ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This makes total sense yes, wasmtypes.AllowNobody is the desired param for both

MsgStoreAndInstantiateContract looks like it will allow the uploader (gov) to override the AccessConfig though for instantiates. InstantiateContractProposal does not have this.

I would assume this overrides the defaults since gov approved, which is a feature but actually a bug in our case for expected behavior. i.e. need to ante block a proposal if MsgStoreAndInstantiateContract.instantiate_permission is set

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I'm getting it, thanks!

We will address those concerns before testnet and write new docs before cosmwasm lands on the hub mainnet.

app/upgrades/v16/upgrades.go Fixed Show resolved Hide resolved
app/upgrades/v16/upgrades.go Fixed Show resolved Hide resolved
@Reecepbcups
Copy link
Member Author

Reecepbcups commented Apr 9, 2024

Upgrade works locally with versions but not here, odd.
image

@Reecepbcups Reecepbcups marked this pull request as ready for review April 10, 2024 00:00
Copy link
Member

@webmaster128 webmaster128 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great stuff 🎉 I'm sure you know the Go integration part better than myself

.goreleaser.yml Show resolved Hide resolved
@@ -20,10 +20,8 @@ builds:
goos:
- darwin
- linux
- windows
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On Windows we can still build a client binary (through some build flags). However, the contract execution on Windows is not supported.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure if goreleaser lets you specify the GOOS=windows GOARCH=amd64 go build $(BUILD_FLAGS) -o build/gaiad.exe ./cmd/gaiad for just 1 type of arch. Will have to look more into

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can take a look at this but I think you're right about the env vars.

Dockerfile Outdated Show resolved Hide resolved
Dockerfile Outdated Show resolved Hide resolved
Dockerfile Outdated Show resolved Hide resolved
Dockerfile Outdated Show resolved Hide resolved
app/keepers/keepers.go Outdated Show resolved Hide resolved
e2e.Dockerfile Outdated Show resolved Hide resolved
sed -i '' 's/timeout_commit = "5s"/timeout_commit = "1s"/g' ~/.gaia/config/config.toml
sed -i '' 's/timeout_propose = "3s"/timeout_propose = "1s"/g' ~/.gaia/config/config.toml
sed -i '' 's/index_all_keys = false/index_all_keys = true/g' ~/.gaia/config/config.toml
# sed -i '' 's#"tcp://127.0.0.1:26657"#"tcp://0.0.0.0:26657"#g' ~/.gaia/config/config.toml
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These scripts probably need to be redone tbh. Happy to do if the team would like. Maybe another PR

ref what I use: https://github.com/CosmosContracts/juno/blob/main/scripts/test_node.sh

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have this in the backlob but we haven't started refactoring yet: #2950

We can add refactoring this script to that issue and do them all in a different PR.

@MSalopek
Copy link
Contributor

@Reecepbcups
Hey, thanks for the your contribution! Clearly, there was quite a lot of work that went into this and we appreciate the effort!

I'd like to help pass all the checks (upgrade tests, e2e etc.) if you don't mind me adding to the PR?

As for merging this, the v16 release is already feature frozen and will be cut tomorrow morning (European time) as we have already prepared all the testing pipelines and made plans for the testnet upgrades. It's a pretty beefy release adding IBC features voted in by governance.

I think it should be pretty safe to merge this into main once we finalize the v16 release branch.

I'm really excited about this 🚀

@Reecepbcups
Copy link
Member Author

@MSalopek Thanks and Sounds good on the v16 front. Yes, Maintainer edits are enabled.

Copy link

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@github-actions github-actions bot added the stale label May 27, 2024
@Reecepbcups
Copy link
Member Author

Reecepbcups commented May 27, 2024

I’ll pull in main Tuesday in prep for v18*

@stale stale bot removed the stale label May 27, 2024
Conflicts resolved.
Upgrade moved to gaia/v18
@MSalopek
Copy link
Contributor

I’ll pull in main Tuesday in prep for v17

I already merged main into the branch (maintainer edits are enabled on the wasm-integration branch). I'm fixing tests.

v17 is already cut and the propsal is in voting (it has partial set security features enabled with some other goodies).
This brings a major change for the ICS protocol and all consumer chains so it was made into its own release.

v18 is next with cosmwasm, ibc-go v7.5.0 and some other upgrades. The PR will be merged as soon as all tests are passing and we provide a definite answer regarding this discussion: #3051 (comment).

The relatively fast upgrade cadence enables us to push out more features in distinct releases so we offset some risks around the upgrade.

ENV PACKAGES curl make git libc-dev bash gcc linux-headers eudev-dev python3
RUN apk add --no-cache $PACKAGES
RUN CGO_ENABLED=0 make install
RUN LEDGER_ENABLED=false LINK_STATICALLY=true BUILD_TAGS=muslc make build
Copy link
Contributor

@MSalopek MSalopek May 27, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Had issues with this in e2e.

CGO needs to be enabled (don't know why).
I've also had to add RUN apk add --no-cache build-base in the runner container to make CGO available.

It seems that we cannot run the tests without CGO enabled.

I'm not sure what the implications of this are. While checking other projects, they all seem to be running with CGO enabled (or at least they don't explicitly disable it using CGO_ENABLED=0.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This repo contains both Rust and Go code. The Rust code is compiled into a library (shared .dll/.dylib/.so or static .a) to be linked via cgo and wrapped with a pleasant Go API

CGO is a requirement for CW yes https://github.com/CosmWasm/wasmvm

@mergify mergify bot mentioned this pull request May 29, 2024
Copy link
Contributor

@MSalopek MSalopek left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks again for the PR!

All tests were cleaned up, the upgrade is passing.

There's a bit of work to do later.
We still need to check the goreleaser settings, update Dockerfile and make better upgrade tests.

The build got a bit complicated given the libwasmvm dep that can be either statically or dynamically linked. upgrade-test is using a dynamic linking approach while dockerized build uses static linking.

We will need to expand the build docs to show how to build with cosmwasm in mind.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants