Stargate upgrade

[Join the Cosmos Stargate announcements channel!](Cosmos Stargate announcements channel!)

If you’re running a block explorer, wallet, exchange, validator, or any other service (eg. custody provider) that depends upon the Cosmos Hub or Cosmos ecosystem, you’ll want to pay attention, because this upgrade will involve substantial changes.

• Inter-Blockchain Communication (IBC)– cross-chain transactions
• Protobuf Migration – blockchain performance & dev acceleration
• State Sync – minutes to sync new nodes
• Full-Featured Light Clients
• Chain Upgrade Module – upgrade automation

Help us to get the word out–this is a major leap for the Cosmos Network and we want everyone on board 🚀

Testnet

We've now launched the Cosmos Hub Stargate testnet cosmoshub-test-stargate for the Stargate simulated upgrade on October 28, 2020

cosmoshub-test-stargate is based on Cosmos SDK-0.40-rc3.

The following features are live on the testnet.

• Legacy Amino
• IBC
• State-Sync
• Cosmovisor

This testnet is intended to be a simulation testnet for Cosmos Hub-3

Simulated CosmosHub-3 Upgrade

A test migration command targeted the blockheight dated around 11/01/2020 for the migration was as follows:

Step 1:

git clone https://github.com/cosmos/gaia
git checkout cosmoshub-test-stargate
make build

Step 2: The Cosmos Hub-3 genesis snapshot of hub at block height 3924406 is here: ttps://storage.googleapis.com/stargate-genesis/3924406.cosmoshub-3.json

Step 3: There is a full copy of a cosmos hub full node here: https://storage.googleapis.com/stargate-genesis/snapshot.tgz

Step 4: Using Gaia 2.0 and this cosmos node above,

gaiad export > 3924406.cosmos_hub_3.json

Step 5: Using the crowdsourced public keys from the Stargate repo:

build/gaiad migrate ~/3924406.cosmos_hub_3.json --chain-id=cosmoshub-test-stargate --initial-height 3924407 --replacement-cons-keys ~/stargate/validator_replacement.json > migrated_genesis.json

jq . migrated_genesis.json > genesis.json

To simplify testing, we manually adjusted some governance parameters.

      {
      "tally_params": {
        "quorum": "0.050000000000000000",
        "threshold": "0.500000000000000000",
        "veto_threshold": "0.334000000000000000"
      },
      "votes": [],
      "voting_params": {
        "voting_period": "172800s"
      }
      }

Outcome: The output should match the genesis file at https://storage.googleapis.com/stargate-genesis/genesis.json

shas256sum genesis.json

759413052c854ca75f3bfeec579e3cea00f283646b0ea0d30b6b15e4d13f814b

NOTE:

1. gaiad start will preform an extensive audit of the genesis file state that takes > 1 hour. gaiad start --x-crisis-skip-assert-invariants skips the audits and starts a node in 15 min.

2. We manually went in and edited the quorum and voting period for governance to enable faster testing of the IBC related governance functions in this testnet.

Stargate-5 Testing

• Testing wallets, exchanges and block explorers against the legacy Amino REST interface
• Giving node operators and validators an opportunity to test their integrations against a work in progress version
• Playing with new Stargate features including IBC is possible now with the Akash realyer! Try it out at https://github.com/ovrclk/relayer/releases/tag/stargate-4

Our validator node for a persistent peer is available at

[email protected]:26656

For users who want to test state sync, our validator node has tendermint rpc open on 34.66.55.131:26657and we are snapshotting every 1000 blocks.

As of 11/11/2020, the tagged gaia version is cosmoshub-test-stargate

Remember this version now has a single binary instead of gaiacli/gaiad and much more configurable app.toml

git clone https://github.com/cosmos/gaia
git checkout cosmoshub-test-stargate
make build

Statesync Configuration Options

State sync rapidly bootstraps a new node by discovering, fetching, and restoring a state machine snapshot from peers instead of fetching and replaying historical blocks. Requires some peers in the network to take and serve state machine snapshots. State sync is not attempted if the node has any local state (LastBlockHeight > 0). The node will have a truncated block history, starting from the height of the snapshot.

In the Tendermint config file there is a state-sync section. Some of these fields must be filled in order to use state-sync.

To find out how to fill in this information please visit: https://docs.tendermint.com/master/tendermint-core/state-sync.html

Additionally, some nodes in the network must take state sync snapshots, which are configured in app.toml:

Snapshot-interval specifies the block interval at which local state sync snapshots are taken (0 to disable). Must be a multiple of pruning-keep-every.

NOTE: Please set this value to a non-zero value. This is required in order for other nodes to be able to utilize state-sync.

snapshot-interval = {{ .StateSync.SnapshotInterval }}

Snapshot-keep-recent specifies the number of recent snapshots to keep and serve (0 to keep all).

snapshot-keep-recent = {{ .StateSync.SnapshotKeepRecent }}

These are disabled by default, out of caution - this is new code, and we wouldn't want it to cause a chain-wide halt or data corruption. Eventually we can consider enabling them by default.

• Week 1 Status July 2nd, 2020

• Week 2 Status July 11th, 2020

• Week 3 Status July 17th, 2020

• Week 4 Status July 27th, 2020

• Week 5 Status August 7th, 2020

• Week 6 Status August 12th, 2020

• Week 7 Status August 19th, 2020

• Week 8 Status August 26th, 2020

• Week 9 Status September 6th, 2020

• Week 10 & 11 Status September 16th, 2020

• Week 12 Status September 23, 2020

• Project Board