End-of-year release!
It has been an eventful 2022 in many ways, both good and bad, so why not end it with a great Wasmd release?
We had a large number of community feature requests to review and prioritize, and we are happy to announce that with Wasmd v0.30, we managed to get many of them in this end-of-year release.
As usual, a big thank you to all contributors who made this release possible!
Overview ( TLDR )
Wasmd v0.30 contained quite a few heavily community-requested changes, besides the usual bug fixes and improvements, we also shipped the following:
- Authz module integration
- IBC upgrade to v4.2.0 with interchain-accounts v0.2.4
- Add Developer’s guide and best practices
- Bump Go minimum to 1.19
- Store and instantiate gov proposal
- Allow gov votes to upload larger wasm bytecode
- Introduce AcceptListStargateQuerier
- Get Contracts by Creator Address
- Support instantiation permission > chain permission for gov store
The Details
Authz module integration
The authz module is a Cosmos-SDK module to grant authorizations to a different account (grantee) and to execute actions on chain on behalf of the original account (granter).
This is especially useful to protect the private account key as it is only needed for the grant operation, but then the grantee key can be used. This can also be helpful to match organizational or process structures where access to the granter private key is limited.
A granted authorization comes with a lot of power as it is executed with the account of the granter. Therefore, certain authz extensions exist in other modules that limit the scope of the actions. For example, in bank. Authorization, the total amount of tokens, is defined that can be transferred.
The authz module comes with a generic authorization that accepts a message type. This works with any Cosmos module, including wasmd. The problem there is that wasm contracts do normally support a number of operations, and fine-grained access control would not be possible.
The wasmd Authorization extension was built to support a finer level of access control. Filters can be defined to match the contract message on execution and migration. Wasmd comes in the first iteration with the following filters:
AllowAllMessagesFilter — wildcard to match any contract message
AcceptedMessageKeysFilter — the contract messages are interpreted as a json object with exactly one key. This key can be set in an acceptlist to be accepted. For example, with ` withdraw, delegate` set, the `{“withdraw”: {}}` and `{“delegate”:{}}` messages are allowed but `{“sent”:{}}` is not as the key is not in the list.
AcceptedMessagesFilter — this filter does not make assumptions about the contract message. They are interpreted as pure binary data and compared. Small changes in the formatting do already matter. For example, with {"withdraw":{}} set contract message must be {"withdraw":{}} while {"withdraw":{} }would be rejected (note the spaces).
The benefit of this filter, though, is that it also contains the data after the object key. For example, {"vote":"yes"}can not be changed to {"vote":"no"}
Another element of the wasmd Authorization extension is the limits. As the operation is executed in the scope of the granter account, it has full access to their bank balances. The granter has some interest in limiting this and staying in control. For example, a {“withdraw”:{}} operation may not need access to the balance while the {“delegate”:{}} does. In order to support the different use cases, we have the following limits that can be set with the filters:
MaxCallsLimit — define how many times a contract grant can be used, no token transfer from the granter account allowed.
MaxFundsLimit — sets a token budget to be spent, no limit on the number of calls.
CombinedLimit — sets a token budget and how many executions can be made
The limits are updates after each grant execution. When the limit lapses, then the authorization ends and is removed.
Further reading:
https://github.com/cosmos/cosmos-sdk/tree/main/x/authz
IBC upgrade to v4.2.0 with interchain-accounts v0.2.4
This upgrade includes IBC protocol handshake and the fee middleware module, interchain-accounts v0.2.4, as well as it updates the ibctesting package.
Further reading:
https://github.com/CosmWasm/wasmd/issues/960
https://github.com/cosmos/ibc-go/blob/v4.2.0/CHANGELOG.md
Add Developer’s guide and best practices.
The coding guidelines have been updated to make it easier for newcomers as well as more experienced developers to find and orient themselves. Best practices were also added, and the new and updated guide can be found here:
Bump Go minimum to 1.19
To follow the cosmos-SDK, the minimum Go version was bumped to 1.19, which also prevents consensus issues on a mixed Go 1.18/19 chain.
Further reading:
https://github.com/CosmWasm/wasmd/issues/1041
Store and instantiate gov proposal
In earlier versions, upload wasm (store) and instantiate contract required 2 separate gov proposals.
Now there is a new gov proposal type that allows both steps to be executed as one.
So now we have less organizational overhead and dependency on creating proposals. (As store had to be scheduled and executed before instantiate)
Further reading:
https://github.com/CosmWasm/wasmd/issues/785
Allow gov votes to upload larger wasm bytecode.
We used to limit wasm size to 800 KB, which was reasonable for most contracts, as it could be undesirable to raise the global limit of the chain; it was proposed that gov contracts could serve this function and allow wasm sizes of up to 4 MB at the same time as normal Tx stays at 800 KB.
Further reading:
Introduce Accept List Stargate Querier
Stargate queries are a powerful generic extension point to query system state via the “Stargate” generic protobuf format. With this chain, agnostic data can be queried by a contract, like a liquidity pool.
This feature caused a lot of issues in the past when the state returned was not deterministic and, therefore, consensus-breaking. We added this accept list to allow every chain to easily configure its own whitelist without maintaining many forks and potentially introducing bugs. Osmosis forked to enable this for their custom modules, and other chains wanted similar functionality.
The accept-list, though, is a way for chain architects to add back support for individual Stargate queries that they want to maintain and support (at their own risk). Now the default accept-list is empty, and you need to set a variable in the Go code of the chain to add any query types you wish to enable.
Further reading:
https://github.com/CosmWasm/wasmd/issues/904
Get Contracts by Creator Address
In earlier versions, we had a query to get all contract instances for a code-id. A popular use case is to give me all contract instances that were created by address x.
As of this release, this is now supported and enables better UX
Further reading:
https://github.com/CosmWasm/wasmd/issues/998
Support instantiation permission > chain permission for gov store
This is also about creating an instance on permissioned chains.
In earlier versions, a store wasm code and a config update on the code instantiation settings were needed; now, with this release, the store gov proposal can set the right instantiation permission already.
This improves the gov workflow and saves one proposal
Further reading:
https://github.com/CosmWasm/wasmd/issues/1020
Get Involved
Like what you see? Let the world know on Twitter or join the discussion on Discord. And remember to follow us on medium to be informed about the upcoming CosmWasm Academy cohorts, or visit http://academy.cosmwasm.com , where you can level up your skills.
And please check out our last Community call of the year, where many exciting announcements will be made on Tue, December 20th at 6 pm CET for more early insights and a space to ask questions.
