This is a store of all the current powers of validators. I don't think this is possible to query from Cosmos SDK, so it needs to be built up from validator set updates.
This is the proposal to create consumer chain 2. First, verify the genesis, download and hash the genesis.json file with the following command: 'curl -s https://paste.c-net.org/DriftedSounding > genesis.json; sha256sum genesis.json'. The outputted hash should match this proposal's 'genesis_hash' field. Now, you can inspect the genesis file to make sure that everything is in order. The 'ccvconsumer' field is empty. It will be filled in after this proposal passes. Next, verify the binary. Follow the steps here https://github.com/sainoe/ICS-testnet/blob/main/join-testnet-tutorial.md#install-the-interchain-security-binary to download and build the binary (it is the same one as used for the first consumer chain, so if you already have it locally, you can skip downloading and building it again). Run this command to get the hash 'sha256sum $(which interchain-security-cd)', and see that it matches this proposal's 'binary_hash' field. Now, you can inspect the binary's source code to make sure that everything is in ord
"This is the proposal to create consumer chain 2. First, verify the genesis, download and hash the genesis.json file with the following command: 'curl -s https://paste.c-net.org/ReaperTrading > genesis.json; sha256sum genesis.json'. The outputted hash should match this proposal's 'genesis_hash' field. Now, you can inspect the genesis file to make sure that everything is in order. The 'ccvconsumer' field is empty. It will be filled in after this proposal passes. Next, verify the binary. Follow the steps here https://github.com/sainoe/ICS-testnet/blob/main/join-testnet-tutorial.md#install-the-interchain-security-binary to download and build the binary (it is the same one as used for the first consumer chain, so if you already have it locally, you can skip downloading and building it again). Run this command to get the hash 'sha256sum $(which interchain-security-cd)', and see that it matches this proposal's 'binary_hash' field. Now, you can inspect the binary's source code to make sure that everything is in orde |
For this consumer chain configuration, we are avoiding everything that could cause a problem. This configuration does not have goverance, and there is no way to change parameters (other than a chain update). There is an optional native token, but it is not a staking token. If the native token is enabled, there is a modified mint module with a fixed inflation percentage as a parameter. If the native token is not enabled, then there are no inflationary rewards on the chain.
Fees can be paid in the native token, or in a token transferred over IBC (such as the Atom). Fees and inflation rewards (fees only if the native token is not enabled), are split in a configurable percentage. One part goes to the provider chain, and the other part goes to a special module on the consumer chain. This module can be customized, but by default it will send the coins on to a configurable personal address or multi-sig.
Changes from a normal Cosmos-SDK chain:
- Staking module is disabled
- Governance module is disabled
- Distribu
For the coordinator:
- Delete old cosmos folder if neccesary:
rm -rf /provider
- Init new genesis and other state:
interchain-securityd init --chain-id provider <your moniker> --home /provider
- Make the keys:
interchain-securityd keys add <your key name> --home /provider
- Add to the genesis:
interchain-securityd add-genesis-account <your address, e.g. cosmos18dnla...> 1000000000stake --home /provider
- Add your gentx, bonding half of the coins:
interchain-securityd gentx <your key name> 500000000stake --chain-id provider --home /provider
- Collect your gentx:
interchain-securityd collect-gentxs --home /provider
- Get the genesis out:
cat /provider/config/genesis.json
- Modify genesis if needed (e.g. shorten unbonding period, voting period, and jailing period), and distribute to other validators
- delete old cosmos folder if neccesary
rm -rf /provider
- init new genesis and other state (i don't know why it needs a moniker)
interchain-securityd init --chain-id provider jehan --home /provider
- make the keys
interchain-securityd keys add jehan --home /provider
- add to the genesis
interchain-securityd add-genesis-account cosmos18dnlag2vt2x0x30zg6m0ncxaalhxp4vl8rpyjl 1000000000stake --home /provider
- add someone else to the genesis
interchain-securityd add-genesis-account cosmos1t0nv6nr2scsa993ujldr7xmww5w66kcxv2cp4f 1000000000stake --home /provider
- get the genesis out
cat /provider/config/genesis.json
- modify genesis if needed
- For other validators: copy the genesis into
/provider/config/genesis.json
- add your gentx, bonding half of the coins here
interchain-securityd gentx jehan 500000000stake --chain-id provider --home /provider
- add anyone else's gentxs
vi /provider/config/gentx/gentx-942a4c70819f7e6464607860fe35237427dc9240.json
- There is chain A and chain B.
- There is also client state A and client state B.
- When client state B is installed on chain A, it enables chain A to correctly prove that stuff has happened on chain B, and vice versa.
- Relayer Jack sends a message to chain A containing client state B and a message to chain B containing client state A. On each chain, these client states are stored under different arbitrary identifiers, which serve as the "network interfaces".
- For example, chain A stores client state B under "foo" and chain B stores client state A under "bar". When client B at interface foo on chain A proves that a packet was sent from chain B, it is said that the packet arrived at interface foo.
- Relayer Jack (or anyone else) can continue to maintain the connection by updating the height of each client state etc.
- The humans can decide if the connection is valid, that is, if packets arriving at interface foo on chain A really represent packets sent from chain B, and if packets arriving at interface bar
[root@988264c069fc /]# ls | |
bin go media run validator-eth-keys | |
boot gravity mnt sbin validator-phrases | |
dev home opt srv validator1 | |
etc lib orchestrator-phrases sys validator2 | |
genesis.json lib64 proc tmp validator3 | |
geth lost+found root usr var | |
[root@988264c069fc /]# cd validator- | |
validator-eth-keys validator-phrases | |
[root@988264c069fc /]# cd validator- |
import { expect } from "chai" | |
import {readFileSync} from 'fs' | |
import { ethers } from "hardhat"; | |
import { Signer } from "ethers"; | |
import { UniswapV2Factory } from "../typechain/UniswapV2Factory"; | |
import { UniswapV2Router02 } from "../typechain/UniswapV2Router02"; | |
import { WETH9 } from "../typechain/WETH9"; | |
import { PSI } from "../typechain/PSI"; | |
import { ChainId, Token, WETH, Fetcher, Route, Router } from '@uniswap/sdk' |
VS Code has remote ssh functionality that is beyond what most people are used to when working with remote computers. It is good enough to make it feel like you are developing locally on a much faster computer. It is a very different experience from SSH in a terminal.
- Full file explorer
- Full terminal
- All VS Code plugins are brought over automatically
- VS Code plugins are also accelerated by the remote computer, for example linting in Rust
- When the remote computer is on a cloud host such as AWS, dependencies are downloaded very quickly (they are probably hosted in the same data center)
How: