KIRA | Testnet

Before proceeding please ensure that you are meeting the minimum system & software requirements to operate a node. As long as those requirements are met it should be possible to launch a validator and other types of KIRA nodes in a home environment and use off-the-shelf single-board computers such as a Raspberry PI. There are no slashing penalties for validators going offline or becoming temporarily inaccessible. Nodes that go offline for a prolonged period of time will become inactivate and removed from the consensus automatically by the state machine.

The network is designed to halt in the case where ≥ 1/3 of consensus nodes suddenly become unresponsive, however in the case of individual nodes leaving and entering the consensus randomly there should be no interruption to the network operation. As long as the number of validators does not fall below min_validators as defined in Network Properties, the chain will continue producing new blocks.

To ensure the security of the network, we must have Sybil-resistance in place. For this reason, all our testers undergo screening to identify them as unique individuals. Our testers are not just testers; they are recognized as official KIRA Evangelists. This status qualifies them for benefits like grants, bounties, potential validator seats, governance roles, and Universal Basic Income (UBI). They also get access to the private testers chat and more.

On the mainnet, a dedicated governance body can identify non-Sybil operators without the need for Know Your Customer (KYC) protocols or any other personal identification. It's worth noting that there's no limit to the number of validators on either the testnet or the mainnet.

To learn more about the role of an Evangelist or to preview your application, please visit our whitelist page.

Using KIRA Manager (KM) is the quickest way to run your node, as it is a straightforward bash-shell script that can easily create a new personal network or join an existing one on your behalf. However, it is important to note that KM is only intended for internal testing and should not be used on the mainnet. For operating each aspect of the infrastructure manually on the mainnet, please refer to our public documentation page after you have become comfortable and familiar with the process. At present, KM can only be installed on Ubuntu. If you prefer to use a Mac, you will need to install VMware and virtualize the Ubuntu OS. On Windows, WSL2 is supported.

To join an existing network, you will require knowledge of the specific software version you need to run and the IP address of a trusted node operator within that network. You can find all of this information conveniently located in the "Active Testnets" section below, so there is no need to worry. Let us now examine some simple setup examples.

Once you have accepted the initial terms and conditions, you will be presented with the Launcher Menu, which enables you to configure your node, manage networking settings, download snapshots, and preview the hash of a genesis file. Within the Node Launcher Menu, you will need to specify the IP address of a trusted seed node or another validator. Your node will use this connection to synchronize with other nodes on the network and keep its copy of the blockchain up to date. You can request an IP address from any of the fellow validators in the testers’ chat, or use an address of a genesis validator that is listed in the corresponding testnet section below.

Every node has a connection limit and the official genesis validator may be targeted by the DOS/DDOS, and thus become non-operational or non-responsive to the new peers. If this happens, node operators will need to coordinate via the testers’ chat and share between each other IP or DNS addresses of their personal validator, seed, or sentry nodes. Alternatively, testers can utilize any endpoint of an active INTERX node at <IP>:11000/api/pub_p2p_list where <IP> is an IP of any public testnet node to discover more IP addresses.

As a validator, your most important role is to stay online, be an active participant in the testers’ community, and preserve the cryptographic secrets that your node will use to sign new blocks being proposed to the network. There can be many of those “cryptographic secrets” that you need to know about and archive, so we simplified the entire process into just a single set of bip39 mnemonic words that you need to write down. You can visit the Key Management page to learn more or utilize KM to generate it all for you automatically. If you choose to go with KM, please make sure to select option [M] View or Modify Mnemonic before leaving the “Node Launcher Menu” and follow up with [V] Display master mnemonic from keystore within the menu of the “Secrets Manager”.

If by mistake you forgot to write down your mnemonic words, you can always display them by typing the following command in your console window: tryGetVar MASTER_MNEMONIC "$KIRA_SECRETS/mnemonics.env". If your node fails or needs to be recovered, you can regenerate all the secrets by providing the master mnemonic to the KM within the “Node Launcher Menu”. Otherwise, your node will generate a new set of secrets every time you set up a new node on a fresh instance.

If you ever need to fully recover your validator node, including all its secrets and private keys, you can do so by importing the mnemonic that you previously wrote down. To access this option, simply select[M] Modify master mnemonic and DELETE all secrets from the main menu of the “Secrets Manager”. However, it is important to note that this process will destroy all auto-generated secrets and replace them with the ones derived from your master mnemonic. You should be very careful when using this option and ensure that you have a backup of your master mnemonic in a secure location. It is also crucial to never attempt to recover your validator or reuse your secrets on two machines simultaneously. Doing so will result in the double signing of a block and lead to your node being jailed.

To join the validator set you will need to become an official KIRA tester first. Your initial goal will be to determine your validator public address, which you will need to submit as part of the application process to become whitelisted.

Once you have completed the installation process, you can easily find your validator address by typing kira into your terminal window to open KIRA Manager. From there, simply press the corresponding number on your keypad to designate your validator container (usually [0] by default). You will then be presented with a container manager that provides statistics about your node, including your Validator Address.

Once you have been whitelisted by the testnet support team, you will be presented with an explicit option to [J] Join Validator Set in the main menu of KIRA Manager. Upon executing this option, your node will begin to produce and sign proposed blocks. In addition to this, the main menu of KIRA Manager provides many other options such as configuring the firewall or creating snapshots.

The main highlight of all KIRA testnets is collaboration on performing automated on-chain upgrades. Our upgrade module is a blockchain application that allows validators to coordinate soft & hard forks as well as agree on the integrity and content of each new KIRA release. KIRA Manager will automatically detect upcoming changes, delete all containers, perform snapshots & genesis file exports then rebuild the environment and launch a new release without your assistance. You can enable or disable automated upgrades from within your KM, by selecting option [U]. You will also be notified via the KM of the exact time of the upcoming upgrade. All upgrades are scheduled according to timestamps predefined in the upgrade proposals and NOT block-height based thus making it way more predictable to coordinate and apply changes regardless if you plan to use KM or a dedicated continuous deployment (CD) pipeline for your infrastructure.

It is mandatory for ALL validators to vote on upgrade proposals. If you skip the vote then the on-chain status after the upgrade will be changed to inactive and you will not be producing blocks while your validator leaderboard rank will significantly decrease.

If you do not wish to use KM and instead utilize your own dedicated continuous deployment (CD) tools, then you can acquire informations about upcoming upgrades from either the sekai CLI or the following two INTERX endpoints:

The “current” plan contains informations & resources regarding the current release while the “next” plan contains informations & resources regarding upcoming releases. You can also use resource references specified in the “current” plan endpoint of a trusted node while joining the network for the very first time. If you choose not to use KM and a new genesis file is required (hard fork), you can create it by first exporting genesis at the height where the network stopped (your node daemon should be shut down) and then passing it through a dedicated new-genesis-from-exported command.