[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 🚀
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
A test migration command targeted the blockheight dated around 11/01/2020 for the migration was as follows:
Step 1:
cd ~/
git clone https://github.com/cosmos/gaia
git clone https://github.com/cosmosdevs/stargate
cd gaia
git checkout cosmoshub-test-stargate-e
make buildStep 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.jsonStep 5: Using the crowdsourced public keys from the Stargate repo:
build/gaiad migrate ~/3924406.cosmoshub-3.json --chain-id=cosmoshub-test-stargate-d --initial-height 3924407 --replacement-cons-keys ~/stargate/validator_replacement.json > migrated_genesis.json
jq . migrated_genesis.json > genesis.jsonTo simplify testing, we manually adjusted some governance parameters.
{
"tally_params": {
"quorum": "0.010000000000000000",
"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
4b552ed850946ab43a7025ca6925ddb1a86fc9c78ed50a6762bbb1bd0a5797b0
NOTE:
-
gaiad startwill preform an extensive audit of the genesis file state that takes > 1 hour.gaiad start --x-crisis-skip-assert-invariantsskips the audits and starts a node in 15 min. -
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.
[email protected]:26656
- 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]:26656For 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 buildState 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.