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

docs: update migration docs for merkle path v2 changes #6757

Merged
merged 8 commits into from
Jul 9, 2024
88 changes: 88 additions & 0 deletions docs/docs/03-light-clients/04-wasm/09-migrations.md
Original file line number Diff line number Diff line change
Expand Up @@ -9,6 +9,94 @@ slug: /ibc/light-clients/wasm/migrations

This guide provides instructions for migrating 08-wasm versions.

## From v0.2.0+ibc-go-v8.3-wasmvm-v2.0 to v0.3.0-ibc-go-v8.3-wasmvm-v2.0
damiannolan marked this conversation as resolved.
Show resolved Hide resolved

### Contract developers

The `v0.3.0` release of 08-wasm for ibc-go `v8.3.x` and above introduces a breaking change for client contract developers.

The contract API `SudoMsg` payloads `VerifyMembershipMsg` and `VerifyNonMembershipMsg` have been modified.
The encoding of the `Path` field of both structs has been updated from `v1.MerklePath` to `v2.MerklePath` to support proving values stored under keys which contain non-utf8 encoded symbols.

As a result, the `Path` field now contains a `MerklePath` composed of `key_path` of `[][]byte` as opposed to `[]string`. The JSON field `path` containing `key_path` of both `VerifyMembershipMsg` and `VerifyNonMembershipMsg` structs will now marshal elements as base64 encoded bytestrings. See below for example JSON diff.

```diff
{
"verify_membership": {
"height": {
"revision_height": 1
},
"delay_time_period": 0,
"delay_block_period": 0,
"proof":"dmFsaWQgcHJvb2Y=",
"path": {
+ "key_path":["L2liYw==","L2tleS9wYXRo"]
- "key_path":["/ibc","/key/path"]
},
"value":"dmFsdWU="
}
}
```

A migration is required for existing 08-wasm client contracts in order to correctly handle the deserialisation of `key_path` from `[]string` to `[][]byte`.
Contract developers should familiarise themselves with the migration path offered by 08-wasm [here](./05-governance.md#migrating-an-existing-wasm-light-client-contract).

An example of the required changes in a client contract may look like:

```diff
#[cw_serde]
pub struct MerklePath {
+ #[schemars(with = "String")]
+ #[serde(with = "Base64", default)]
+ pub key_path: Vec<Bytes>,
- pub key_path: Vec<String>,
}
Copy link
Contributor Author

@damiannolan damiannolan Jul 3, 2024

Choose a reason for hiding this comment

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

@srdtrk, could you confirm if this is correct unmarshalling syntax for []string -> [][]byte? I can also modify the composable-ibc grandpa-cw contract and try to test this

this was based on code here: https://github.com/ComposableFi/composable-ibc/blob/main/light-clients/ics10-grandpa-cw/src/msg.rs#L150-L167

I'm unsure if Bytes is some kind of alias or not. Is Vec<Vec<u8>> valid syntax also? Maybe with the alias is fine...

Copy link
Member

Choose a reason for hiding this comment

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

This wouldn't work

Copy link
Contributor

Choose a reason for hiding this comment

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

What would be the right way to do it, @srdtrk?

Copy link
Member

Choose a reason for hiding this comment

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

We've decided to replace the usage of Bytes with cosmwasm_std::Binary

Copy link
Contributor Author

Choose a reason for hiding this comment

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

https://docs.rs/cosmwasm-std/2.0.4/cosmwasm_std/struct.Binary.html

Binary is a wrapper around Vec to add base64 de/serialization with serde. It also adds some helper methods to help encode inline.

This is only needed as serde-json-{core,wasm} has a horrible encoding for Vec. See also https://github.com/CosmWasm/cosmwasm/blob/main/docs/MESSAGE_TYPES.md.

```

## From v0.1.1+ibc-go-v7.3-wasmvm-v1.5 to v0.2.0-ibc-go-v7.6-wasmvm-v1.5
damiannolan marked this conversation as resolved.
Show resolved Hide resolved

### Contract developers

The `v0.2.0` release of 08-wasm for ibc-go `v7.6.x` and above introduces a breaking change for client contract developers.

The contract API `SudoMsg` payloads `VerifyMembershipMsg` and `VerifyNonMembershipMsg` have been modified.
The encoding of the `Path` field of both structs has been updated from `v1.MerklePath` to `v2.MerklePath` to support proving values stored under keys which contain non-utf8 encoded symbols.

As a result, the `Path` field now contains a `MerklePath` composed of `key_path` of `[][]byte` as opposed to `[]string`. The JSON field `path` containing `key_path` of both `VerifyMembershipMsg` and `VerifyNonMembershipMsg` structs will now marshal elements as base64 encoded bytestrings. See below for example JSON diff.

```diff
{
"verify_membership": {
"height": {
"revision_height": 1
},
"delay_time_period": 0,
"delay_block_period": 0,
"proof":"dmFsaWQgcHJvb2Y=",
"path": {
+ "key_path":["L2liYw==","L2tleS9wYXRo"]
- "key_path":["/ibc","/key/path"]
},
"value":"dmFsdWU="
}
}
```

A migration is required for existing 08-wasm client contracts in order to correctly handle the deserialisation of `key_path` from `[]string` to `[][]byte`.
Contract developers should familiarise themselves with the migration path offered by 08-wasm [here](./05-governance.md#migrating-an-existing-wasm-light-client-contract).

An example of the required changes in a client contract may look like:

```diff
#[cw_serde]
pub struct MerklePath {
+ #[schemars(with = "String")]
+ #[serde(with = "Base64", default)]
+ pub key_path: Vec<Bytes>,
- pub key_path: Vec<String>,
}
```

## From ibc-go v7.3.x to ibc-go v8.0.x

### Chains
Expand Down
2 changes: 1 addition & 1 deletion docs/docs/05-migrations/13-v8-to-v9.md
Original file line number Diff line number Diff line change
Expand Up @@ -183,7 +183,7 @@ The `IterateConsensusMetadata` function has been removed.

### 08-wasm

- The `VerifyMembershipMsg` and `VerifyNonMembershipMsg` payloads for `SudoMsg` have been extended to include a new field, `MerklePath`. The existing `Path` field will remain the same. The new `MerklePath` field is used if and only if the provided key path contains non-utf8 encoded symbols, and as a result will encode the JSON field `merkle_path` as a base64 encoded bytestring. See [23-commitment](#23-commitment).
- The `VerifyMembershipMsg` and `VerifyNonMembershipMsg` payloads for `SudoMsg` have been modified. The `Path` field of both structs has been updated from `v1.MerklePath` to `v2.MerklePath`. The new `v2.MerklePath` field contains a `KeyPath` of `[][]byte` as opposed to `[]string`, see [23-commitment](#23-commitment). This supports proving values stored under keys which contain non-utf8 encoded symbols. As a result, the JSON field `path` containing `key_path` of both messages will marshal elements as a base64 encoded bytestrings. This is a breaking change for 08-wasm client contracts and they should be migrated to correctly support deserialisation of the `v2.MerklePath` field. See [08-wasm migrations](../03-light-clients/04-wasm/09-migrations.md) for more information.
- The `ExportMetadataMsg` struct has been removed and is no longer required for contracts to implement. Core IBC will handle exporting all key/value's written to the store by a light client contract.
- The `ZeroCustomFields` interface function has been removed from the `ClientState` interface. Core IBC only used this function to set tendermint client states when scheduling an IBC software upgrade. The interface function has been replaced by a type assertion.

Expand Down
Loading