certusone
/
wasmd
mirror of https://github.com/certusone/wasmd.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Merge PR #205: Update Migration Doc with Proposal Values

This commit is contained in:
Alexander Bezobchuk 2019-12-03 10:29:58 -05:00 committed by GitHub
parent ba07766fce
commit 477a2235dc
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 11 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

21
docs/migration/cosmoshub-2.md
View File

@ -5,8 +5,9 @@ must take in order to upgrade from `cosmoshub-2` to `cosmoshub-3`. The Tendermin
will post an official updated genesis file, but it is recommended that validators
execute the following instructions in order to verify the resulting genesis file.
There is a strong social consensus around proposal [PLACEHOLDER] on `cosmoshub-2`.
This indicates that the upgrade procedure should be performed on [PLACEHOLDER] on block [PLACEHOLDER].
There is a strong social consensus around proposal `Cosmos Hub 3 Upgrade Proposal E`
on `cosmoshub-2`. This indicates that the upgrade procedure should be performed
on `December 11, 2019 at or around 14:27 UTC` on block `2,902,000`.
- [Preliminary](#preliminary)
- [Major Updates](#major-updates)
@ -84,11 +85,11 @@ v0.34.6+ of the _Cosmos SDK_ and restore to their latest snapshot before restart
__Note__: It is assumed you are currently operating a full-node running v0.34.6+ of the _Cosmos SDK_.
- The version/commit hash of Gaia v2.0.3: `2f6783e298f25ff4e12cb84549777053ab88749a`
- The upgrade height as agreed upon by governance: **[PLACEHOLDER]**
- The upgrade height as agreed upon by governance: **2,902,000**
- You may obtain the canonical UTC timestamp of the exported block by any of the following methods:
- Block explorer (e.g. [Hubble](https://hubble.figment.network/cosmos/chains/cosmoshub-2/blocks/[PLACEHOLDER]?format=json&kind=block))
- Through manually querying an RPC node (e.g. `/block?height=[PLACEHOLDER]`)
- Through manually querying a Gaia REST client (e.g. `/blocks/[PLACEHOLDER]`)
- Through manually querying an RPC node (e.g. `/block?height=2902000`)
- Through manually querying a Gaia REST client (e.g. `/blocks/2902000`)
1. Verify you are currently running the correct version (v0.34.6+) of the _Cosmos SDK_:
@ -111,7 +112,7 @@ __Note__: It is assumed you are currently operating a full-node running v0.34.6+
Before exporting state via the following command, the `gaiad` binary must be stopped!
```shell
$ gaiad export --for-zero-height --height=[PLACEHOLDER] > cosmoshub_2_genesis_export.json
$ gaiad export --for-zero-height --height=2902000 > cosmoshub_2_genesis_export.json
```
3. Verify the SHA256 of the (sorted) exported genesis file:
@ -152,13 +153,13 @@ v2.0.3 of [Gaia](https://github.com/cosmos/gaia).
**NOTE**: The `migrate` command takes an input genesis state and migrates it to a targeted version.
Both v0.36 and v0.37 are compatible as far as state structure is concerned.
Genesis time should be computed relative to the blocktime of [PLACEHOLDER]. The genesis time shall be
the blocktime of [PLACEHOLDER] + [PLACEHOLDER] minutes with the subseconds truncated.
Genesis time should be computed relative to the blocktime of `2,902,000`. The genesis time
shall be the blocktime of `2,902,000` + `60` minutes with the subseconds truncated.
An example shell command(tested on OS X Mojave) to compute this values is:
```shell
curl https://stargate.cosmos.network:26657/block\?height\=1933000 | jq -r '.result["block_meta"]["header"]["time"]'|xargs -0 date -v +60M -j -f "%Y-%m-%dT%H:%M:%S" +"%Y-%m-%dT%H:%M:%SZ"
curl https://stargate.cosmos.network:26657/block\?height\=2902000 | jq -r '.result["block_meta"]["header"]["time"]'|xargs -0 date -v +60M -j -f "%Y-%m-%dT%H:%M:%S" +"%Y-%m-%dT%H:%M:%SZ"
```
7. Now we must update all parameters that have been agreed upon through governance. There is only a
@ -211,4 +212,4 @@ single parameter, `max_validators`, that we're upgrading based on [proposal 10](
5. We expect that developers with iOS or Android based apps may have to notify their users of downtime
and ship an upgrade for cosmoshub-3 compatibility unless they have some kind of switch they can throw
for the new tx formats. Server side applications should experience briefer service interruptions and
be able to just spin up new nodes and migrate to the new apis
be able to just spin up new nodes and migrate to the new apis.