KIRA Network Public Testnet

Hardware & Software Prerequisites

• 4 vCPU cores (ARM64 or x64)
• Minimum 8GB of RAM
• Storage space required to persist blockchain state and snapshots (512GB+ recommended)
• Minimum 32GB+ of the free storage space available at all times
• Disposable cloud instance or VM
• Ubuntu 20.04 LTS installed on the host instance or VM
• Stable internet connection with minimum 10 Mbps Up/Dn speed
• Static IP address or dynamic DNS
• Access to router or otherwise your local network configuration

Infrastructure Setup

Overview

• Execute Setup Instruction
  • As branch name input testnet-* (* - see list below for the latest number)
• Verify Kira Manager Checksum
  • Click [V] to accept
• Select Sentry or Validator Mode
• Click [S] to start setup
  • Input Address of the Public Seed Node and follow instructions on the screen.
• Backup Auto-Generated Private Keys

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:

• With KM: voteYes <UPGRADE-PROPOSAL-ID> validator
• Without KM: sekaid tx customgov proposal vote <UPGRADE-PROPOSAL-ID> 1 --from=$ACCOUNT --chain-id=$NETWORK_NAME --keyring-backend=test --fees=100ukex --yes --log_format=json --broadcast-mode=async --output=json

Networks, Checksums & References

Testnet-9 (latest)

• Chain Identifier: testnet-9
• Expected Hard Fork Date: 2022-01-07 6:30 PM UTC
• Upgrade Proposal Id: 668
• Kira Manager Checksum: 0feca1c125f2291596dd115ff2cf720032a7098030f8aa97c164afa9ca79644e
• Genesis File Checksum: 0x111567fa0152bc91d72e395d3604510b8425e4b3a9c48cca1e9d019fdde749f8
• Genesis File Source: link
• Initial Block Height: 920527
• Block Height Reached: TBD

Testnet-8

• Chain Identifier: testnet-8
• Kira Manager Checksum: 0feca1c125f2291596dd115ff2cf720032a7098030f8aa97c164afa9ca79644e
• Genesis File Checksum: 0x8b688297b8a6f0ce9924eb163a4c254dfe647fe1b0c0d891cff9457869e650b7
• Genesis File Source: link
• Initial Block Height: 138403
• Block Height Reached: 920527

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

• Chain Identifier: testnet-7
• Kira Manager Checksum: 0feca1c125f2291596dd115ff2cf720032a7098030f8aa97c164afa9ca79644e
• Genesis File Checksum: 0x3c7d72740fbd6f840e9757feaa81a3575cabbdb0a213c1e2c1e30913b8771274
• Genesis File Source: link
• Public Seed Nodes List: link
• Initial Block Height: 2500
• Block Height Reached: 138403

Post Mortem

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

Testnet-6

• Chain Identifier: testnet-6
• Expected Launch Time: 1635028200
• Kira Manager Checksum: 199a3454d4e88a152d8ea05dde33ad9cb8e7475eddbdf0488b4ebff5b2c9ac02
• Genesis File Checksum: bf08fe3cd574ec36eabf165fc4be15ee0e06673e145b3e16ed8480f0829d7ea6
• Genesis File Source: link
• Initial Block Height: 243887
• Block Height Reached: 243887

Post Mortem

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

Testnet-5

• Chain Identifier: testnet-5
• Kira Manager Checksum: 35cfa0e7cee9eaab8c5e84986bbe81780d8c02c6ec76ad385953dc1148d457c0
• Genesis File Checksum: 26efc7a3deb6fe8a1932cfffbbdf47a86f16811defc0b4a9a00575de6d0868cb
• Genesis File Source: link
• Block Height Reached: 243887

Post Mortem

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

Testnet-4

• Chain Identifier: testnet-4
• Kira Manager Checksum: d2de922720744da7e5fa501f78c94d5ce7901744eca81a1796e3a308d7114e31
• Genesis File Checksum: 240b0fe67095e7e25a1e98ba2062231dca0ece81c24f12e8371a31798ade276b
• Genesis File Source: link
• Block Height Reached: 1271603+

Post Mortem

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

Testnet-3

• Chain Identifier: testnet-3
• Kira Manager Checksum: 1837ccd10c21d5e1633751a8c8ce7d7a226ea63a569010a5ff93ad2f02b82d62
• Genesis File Checksum: 85b30bd1e9334299ccfdb39e9385c423f7b43959082ef1d68160ade79c2d6b66
• Genesis File Source: link
• Block Height Reached: 465099

Post Mortem

State machine fault while changing validator set

Testnet-2

• Chain Identifier: testnet-2
• Kira Manager Checksum: e0dcfa5b4b4feba8bdc8665fb47cd0fa587e65984a743b3bc13f2250032e74df
• Genesis File Checksum: 918a64a5ca548b2b4803b96afd06c99cad5302521bdca8271e19e03ffbe879e5
• Genesis File Source: link
• Block Height Reached: 204503

Post Mortem

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

Testnet-1

• Chain Identifier: testnet-1
• Kira Manager Checksum: 26237215b968ecfd201d92c61a13b4c4ce84aa65d57465fe949b2b49f8e66db0
• Genesis File Checksum: d00fd0d0b846a68d93f425ba9655bebae18c31ee5687999935899e5d96b4d0be
• Genesis File Source: link
• Block Height Reached: 49999

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

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