search

KiraCore / testnet

public testnet coordination
Other
31 stars 28 forks source link

readme

KIRA Network Public Testnet

Hardware & Software Prerequisites

Infrastructure Setup

Overview

Setup Instructions

sudo -s

cd /tmp && read -p "Input branch name: " BRANCH && \
 wget https://raw.githubusercontent.com/KiraCore/kira/$BRANCH/workstation/init.sh -O ./i.sh && \
 chmod 555 -v ./i.sh && H=$(sha256sum ./i.sh | awk '{ print $1 }') && read -p "Is '$H' a [V]alid SHA256 ?: "$'\n' -n 1 V && \
 [ "${V,,}" != "v" ] && echo "INFO: Setup was cancelled by the user." || ./i.sh "$BRANCH"

NOTE: Branch name should be the same as chain-id. When prompted to verify checksum press [V] to proceed

Keys Backup Instructions

To persist your private keys type cat /home/<username>/.secrets/mnemonics.env and save the content so that you can recover your accounts easily. Remember to replace <username> with your user name otherwise instruction above will fail.

Keys Recovery Instructions

If you are installing KIRA Manager for the first time on the clean instance you will be prompted during setup to input mnemonic or auto generate a new one, you can also manually recover all your secrets as follows:

Type cd /home/<username> && mkdir ./.secrets && nano ./.secrets/mnemonics.env, then paste your saved secrets and press a combination of Ctrl+o, [ENTER], Ctrl+x to preserve changes. The command above has to be executed before infrastructure setup takes place otherwise it will not take effect during setup. Remember to replace <username> with your user name otherwise new set of keys will be generated.

Joining Validator Set

After submitting request form to join Public Testnet you will receive an on-chain permission to submit claim validator seat transaction. You will see that your node has WAITING status and after sending following transaction from within validator container you will become a KIRA Testnet Validator:

sekaid tx customstaking claim-validator-seat --from validator --keyring-backend=test --home=$SEKAID_HOME \
  --moniker="<Public-Name-Of-Your-Node>" \
  --chain-id=$NETWORK_NAME --fees=100ukex \
  --broadcast-mode=async --yes | txAwait

NOTE: If you are using KIRA Manager simply select [J]oin validator set option. To update your validator moniker, website and other info see the "Identity Registrar & Launch Roadmap" article on the blog.kira.network.

Hard Forks & Soft Forks

All hard and soft forks can be detected via KIRA Manager CLI command showNextPlan or by querying /api/kira/upgrade/next_plan INTERX endpoint, which contains detailed information in regards to time and upcoming software releases. If the instate_upgrade property is set to false a hard fork is expected and genesis file changes are necessary after halt of the chain. If the network is halted due to ongoing hard fork, then validators who do NOT use KIRA Manager should export genesis with the sekaid export command and then convert the exported genesis into a new genesis using sekaid new-genesis-from-exported command. More details in regards to the Hard & Soft forks can be found in the Infrastructure Overview 2.0 article.

It is currently mandatory for ALL validators to vote on upgrade proposals. Example voting commands:

Networks, Checksums & References

Testnet-9 (latest)

Testnet-8

Post Mortem

Was expected to be depreciated due to planned hard fork at 4:30 PM 2022-01-07. During generation of the new genesis file, export tool failed to convert proposal_end_time into minimum_proposal_end_time and jail_max_time into unjail_max_time, resulting in the panic: unknown field "proposal_end_time" & "jail_max_time" in types.NetworkProperties exception and failure to successfully start SEKAI process. After manually fixing network properties in genesis, new issue was found were old proposals become incompatible with the new version of the chain resulting in panic: can't unmarshal Any nested proto *types.SetNetworkPropertyProposal: unknown value "PROPOSAL_END_TIME" for enum kira.gov.NetworkProperty

Testnet-7

Post Mortem

To be depreciated due to planned hard fork at 4:30 PM 2021-11-06

Testnet-6

Post Mortem

Failed to reach 2/3+1 of active validators after hard fork upgrade

Testnet-5

Post Mortem

Depreciated due to planned hard fork at 10:30 PM 2021-10-23

Testnet-4

Post Mortem

Depreciated with a hard fork in order to include automated upgrade module & identity registrar

Testnet-3

Post Mortem

State machine fault while changing validator set

Testnet-2

Post Mortem

Old release of TM caused Denial of Service 2 resulting in the network halt

Testnet-1

Post Mortem

Duplication of the validator when it's added to the validator set by the state machine. Most likely cause was a validator reactivation & validator claim call occurring at the same time or pause/unpause transaction sent in the same block.

Unjailing Stopped Validator Nodes

It might happen that your running validator stops producing blocks due to hardware or software malfunction. As the result of your node halted block production it might become INACTIVE (removed from consensus for ~10 minutes) and thus require sending an activate transaction, by selecting option [A]ctivate in the KIRA Manager main menu, or by inspecting validator container and posting following command into the console:

sekaid tx customslashing activate --from validator --keyring-backend=test --home=$SEKAID_HOME --chain-id=$NETWORK_NAME --fees=1000ukex --broadcast-mode=async --log_format=json --gas=1000000 --broadcast-mode=async --yes | txAwait

picture 2

When validator becomes inactive it's rank on the validators leeboard decreases. To prevent that from happening you can enable [M]aintenance mode which will inform the network that the downtime is planned. After you are ready to join validator set again you can disable the [M]aintenance mode and your validator will again join network operators set without decreasing its ranking position.

You can also enable/disable maintenance mode manually by inspecting your validator container and sending following command to the console window:

# Pausing ACTIVE Node (enabling maintenance)
sekaid tx customslashing pause --from validator --keyring-backend=test --home=$SEKAID_HOME --chain-id=$NETWORK_NAME --fees=1000ukex --broadcast-mode=async --log_format=json --broadcast-mode=async --yes | txAwait

# UnPausing PAUSED Node (disabling maintenance mode)
sekaid tx customslashing unpause --from validator --keyring-backend=test --home=$SEKAID_HOME --chain-id=$NETWORK_NAME --fees=1000ukex --broadcast-mode=async --log_format=json --broadcast-mode=async --yes | txAwait

picture 1