Network Upgrades
To ensure a smooth and coordinated upgrade process, all upgrades will be coordinated by the KIRA testnet support team. Any notifications regarding governance proposals or software changes will be communicated through the testers’ chat. Therefore, it is important to regularly monitor the pinned posts in the chat to stay up to date with the latest information.
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.
Governance proposals voting example
# With KM (voting in favor)
voteYes <proposal-id>
# With KM (voting against)
voteNo <proposal-id>
# Without KM (voting in favor)
sekaid tx customgov proposal vote <proposal-id> 1 --from=$ACCOUNT --chain-id=$NETWORK_NAME \
--keyring-backend=test --fees=100ukex --yes --log_format=json --broadcast-mode=async --output=json
# Without KM (voting against)
sekaid tx customgov proposal vote <proposal-id> 0 --from=$ACCOUNT --chain-id=$NETWORK_NAME \
--keyring-backend=test --fees=100ukex --yes --log_format=json --broadcast-mode=async --output=json
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:
<IP>:11000/api/kira/upgrade/current_plan<IP>:11000/api/kira/upgrade/next_plan
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.
Genesis file upgrade example
# export genesis after ensuring your node is stopped
sekaid export --home=$SEKAID_HOME > ./genesis-export.json
# upgrade release of sekai to the version defined in the on-chain upgrade plan
# execute conversion of the exported genesis file and launch your node using the newly generated genesis
sekaid new-genesis-from-exported ./genesis-export.json ./new-genesis.json --json-minimize=true