Runtime upgrade & mandatory node software update questions

[mochet]

In a while we will be having the nara runtime upgrade which requires validators to upgrade their node software and is mandatory. We currently have 43 validators and I have been working to build better methods of communicating with them and have identified many of the operators but there is always some small risk that validators do not get upgraded prior to the actual runtime upgrade occurring.

Some questions:

1. How long prior to the runtime upgrade will the updated node software become available?
2. Does anyone know what % of validators must successfully upgrade prior to the runtime upgrade at minimum to avoid catastrophic problems?
3. What happens to the nodes that do not upgrade? Do they just stop validating? Is there any risk of stake being slashed? Should I try to also warn nominators to ensure they are only nominating upgraded validators?

[freakstatic]

@mochet good questions! In Nara AFAIK the validator node upgrade is not really mandatory, during the QA tests we tested using only ephesus validators and the network keep running fine but the RPC node needs to upgrade otherwise pioneer will fail to connect to it. But I believe there will be upgrades that really require that validators upgrade their nodes before the runtime upgrade proposal execution.

[mochet]

@mochet good questions! In Nara AFAIK the validator node upgrade is not really mandatory, during the QA tests we tested using only ephesus validators and the network keep running fine but the RPC node needs to upgrade otherwise pioneer will fail to connect to it. But I believe there will be upgrades that really require that validators upgrade their nodes before the runtime upgrade proposal execution.

great, thank you so much for this!

[mnaamani]

If validators choose to run new binary and their hardware doesn't meet minimum hardware specs, they may need to either upgrade their hardware or as a workaround use the https://github.com/Joystream/joystream/blob/7723d06b6995c7ebdcb6a6e3f86c9c077b12ec0e/docker-compose.yml#L13 --no-hardware-benchmarks argument to avoid the node exiting on startup.

reference hardware: https://wiki.polkadot.network/docs/maintain-guides-how-to-validate-polkadot#standard-hardware

[mochet]

If validators choose to run new binary and their hardware doesn't meet minimum hardware specs, they may need to either upgrade their hardware or as a workaround use the

https://github.com/Joystream/joystream/blob/7723d06b6995c7ebdcb6a6e3f86c9c077b12ec0e/docker-compose.yml#L13

--no-hardware-benchmarks argument to avoid the node exiting on startup. reference hardware: https://wiki.polkadot.network/docs/maintain-guides-how-to-validate-polkadot#standard-hardware

Thanks, this is very useful to know. When the time comes and the upgrade is going to be available at a known date I will make sure to issue a communication to all of our validators/nominators on Discord (I have managed to give quite a lot of them a discord role so this will hopefully mean that they can update their software and be aware of any considerations in a timely fashion)

[mochet]

• When the nara node software is run, it will perform a "quick benchmark" that may throw up a warning (The hardware does not meet the minimal requirements for role Authority) that the hardware isn't sufficient to be a validator. This "quick benchmark" may not be adequate to fully test the system, but this warning should ideally not be ignored.
• A tool is available here: https://lib.rs/crates/substrate-benchmark-machine can can run a "full benchmark" and should be used by anyone seeing the warning to ensure their hardware is adequate--this full benchmark may pass fully and if not will explain which particular part of the system is inadequate (CPU, RAM, HDD speed etc)

[mochet]

closing as this runtime already happened quite some time ago